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Chapter  1:  Introduction 


2.1   Background 

A  database  is  a  collection  of  elements  (data  items)  and  relationships  between  these 
elements  which  model  some  application  environment.  At  any  given  point  in  time, 
the  database  will  represent  a  state  of  the  application  environment.  An  update  to 
the  database  represents  a  transition  action  taking  the  database  from  one  state  to 
another.  A  database  model  (or  schema)  provides  a  mechanism  for  representing  the 
elements  of  a  database  along  with  their  relationships.  The  structure  of  a  database 
system  should  parallel  the  structure  of  the  real  world  system  it  represents.  This 
will  allow  for  better  user  understanding  of  the  database  being  designed,  and  allow 
the  use  of  simple  user  front-ends,  which  adheres  to  the  users  understanding  of  the 
system. 

The  semantic  integrity  of  a  database  is  defined  as  how  well  the  database  adheres  to 
the  rules  of  the  application  environment.  Hammer  and  McLeod  [3]  observe  the 
following: 

"Every  ...  application  environment  has  a  set  of  rules  which  define  its 
legitimate  configurations.  Any  correct  version  of  a  data  base  must 
satisfy  these  rules  ....  The  semantic  integrity  of  a  data  base  is  violated 
when  it  ceases  to  represent  a  valid  state  of  its  application  domain, 
because  it  fails  to  adhere  to  some  of  these  rules." 

Conventional    database    models    (e.g.,    Network,    Hierarchical,    CODASYL,    and 

Relational)  have  provided  different  methods  of  representing  data  and  relationships 

in  a  database.  Each  of  these  database  models,  however,  have  been  deficient  in  the 

semantic  integrity  of  the  data  and  relationships  each  represent.    Conventional 


database  models  have  not  adequately  captured  the  meaning  of  data  In  a  real  world 
system.  Hammer  and  McLeod  state  the  following: 

"Conventional  data  models  are  not  satisfactory  for  modeling  data  base 
application  systems.  The  features  that  they  provide  are  too  low  level 
and  representational  to  allow  the  semantics  of  a  data  base  to  be  directly 
expressed  in  the  schema." 

Some  work  has  been  done,  however,  to  extend  the  relational  database  model 
[3][4][10]  to  capture  more  data  meaning. 

Semantic  data  models  have  been  introduced  to  allow  a  database  model  to  better 
describe  the  meaning  of  the  data  it  represents.  Semantic  data  models  typically 
model  the  database  application  using  some  type  of  Data  Definition  Language 
(DDL).  The  DDL  provided  by  a  semantic  data  model  allows  the  use  of  additional 
constructs  to  specify  data  meaning  explicitly.  McLeod  and  King  [5]  give  four 
advantages  of  a  semantic  data  model  over  conventional  database  models: 

1.  it  allows  a  user-oriented  formal  specification  and  documentation  aid  to  be 
established  (in  the  form  of  a  semantic  schema), 

2.  it  provides  a  basis  for  powerful,  high-level  user  interface  facilities, 

3.  it  can  serve  as  a  conceptual  database  model  in  the  database  design  and 
evolution  process,  more  directly  capturing  the  meaning  of  data  then 
conventional  database  models,  and 

4.  it  can  be  used  as  the  database  model  for  a  new  kind  of  database  management 
system,  with  increased  functional  capability  and  improved  user  interface 
characteristics  (compared  with  conventional  DBMSs). 

Two  such  semantic  data  models  are  the  Semantic  Association  Model  (SAM) 

Introduced  by  Su  and  Lo  [7]  and  the  Semantic  Database  Model  (SDM)  introduced 

by  Hammer  and  McLeod  [l].   SAM  and  SDM  are  similar  in  nature.   Each  uses  a 

DDL  to  identify  the  entities  in  the  database  and  list  the  attributes  of  each  entity. 

The  major  difference  is  the  method  used  to  define  the  relationships  between  the 

entities  in  the  database. 


The  Semantic  Database  Model  (SDM)  was  Introduced  by  Hammer  and  McLeod  [l] 
as  a  higher-level  database  model  which  allows  for  greater  semantic  integrity  in  a 
database  schema.  SDM  utilizes  a  formal  specification  approach  to  database 
modeling  by  providing  a  Data  Definition  Language  (DDL).  The  SDM  DDL, 
however,  does  not  enforce  a  strict  syntax.  The  SDM  was  previously  only  used  as  a 
documentation  tool  for  database  modeling  and  had  no  use  for  a  strict  grammar. 
Chapter  2  gives  a  detailed  description  of  the  SDM. 

2.2  High  Level  Project  Description 

It  can  be  seen  from  the  DDL  provided  by  the  SDM  that,  with  a  few  additional 
constraints,  one  could  build  a  static  data  dictionary  from  the  SDM  specification. 
To  perform  this  function  automatically,  the  SDM  specification  would  have  to  take 
on  programming  language  qualities.  The  DDL  provided  by  this  specification  must 
enforce  a  strict  syntax  to  allow  the  DDL  specification  to  be  parsed  by  a  data 
dictionary  generation  tool.  Thus,  the  specification  of  a  SDM  Language  (SDML)  is 
desired. 

The  project  involves  the  generation  of  a  static  data  dictionary  from  an  SDM 
specification.  The  database  designer  will  be  provided  with  a  screen  interface  which 
will  query  for  the  information  required  to  build  an  SDM  for  the  database.  The 
SDM  specification  will  then  be  checked  for  syntactic  and  semantic  correctness. 
Finally,  the  SDM  specification  will  be  used  to  build  a  static  data  dictionary  for  the 
database. 

The  primary  use  of  this  system  will  be  in  developing  under-graduate  skills  in 
database  development.  The  users  of  this  tool  will  have  a  general  knowledge  of  the 
SDM.   The  tool  developed  must  be  IBM  PC  compatible  since  the  under-graduate 
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students  utilizing  the  tool  will  be  using  an  IBM  PC  compatible  system. 
The  project  logically  partitions  itself  into  three  components: 
1.    User  Interface. 

The  user  interface  will  provide  the  interactive  interface  into  the  system.  The 
user  of  the  tool  will  be  queried  for  each  class  definition  for  the  SDM.  The 
user  interface  should  be  as  user-friendly  as  possible  while  generating  a  SDM 
specification  which  is  as  syntactically  sound  as  possible.  This  component 
should  provide  a  listing  of  the  SDM  by  class  and  a  listing  of  the  final  SDM 
specification. 

2.  SDM  Syntax  Specification  and  Parser. 

The  SDM  described  by  Hammer  and  McLeod  does  not  provide  a  strict  syntax 
for  its  DDL.  Since  the  SDM  specification  will,  in  this  project,  be  used  as  an 
intermediate  in  the  generation  of  a  static  data  dictionary,  a  strict  syntax  is 
required.  The  specification  of  a  BNF  for  the  SDM  specification  is  therefore 
required.  Once  this  SDML  is  specified,  a  parser  is  required  to  verify  the  SDM 
generated  by  the  user  interface.  The  parser  will  verify  correct  syntax  of  the 
SDM  generated  as  well  as  some  semantic  checks. 

3.  Data  Dictionary  Generation. 

Once  a  syntactically  correct  SDM  is  generated,  the  data  dictionary  must  be 
generated.  The  data  dictionary  generation  component  will  output  a  valid 
data  dictionary  of  the  database  ordered  by  class. 
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2.3  Low  Level  Project  Description 

This  paper  will  deal  with  the  SDM  syntax  specification  and  parser.  This  will 
involve  the  development  of  a  grammar  for  the  SDM  and  the  specification  of  the 
grammar  in  a  Backus-Naur  Form  (BNF).  This  grammar  will  be  referred  to  as  the 
SDM  Language  (SDML).  The  basic  grammar  rules  will  stem  from  the  SDM 
description  as  given  in  reference  [1].  The  grammar  developed  for  SDML  will  be  a 
deterministic  context-free  grammar.  A  deterministic  grammar  is  one  in  which, 
given  the  next  input  token  and  the  current  state,  only  one  rule  application  is 
possible.  Thus,  a  deterministic  grammar  will  support  the  design  of  a  parser  which 
requires  a  look  ahead  of  only  one  input  token.  Chapter  4  will  describe  the  design 
of  the  grammar  for  SDML. 

Some  extensions  to  the  SDM  will  be  included  in  the  grammar  for  SDML.  These 
extensions  will  be  introduced  and  described  in  Chapter  3.  These  extensions  will 
both  enhance  the  existing  SDM  specification  as  well  as  provide  some  additional 
capabilities  not  provided  by  the  SDM  described  by  Hammer  and  McLeod.  The 
additional  capabilities  introduced  in  this  paper  are  intended  to  add  to  the  semantic 
integrity  of  the  SDM. 

After  the  definition  of  SDML,  the  design  of  an  SDML  parser  will  be  discussed  in 
Chapter  5.  The  parser  designed  will  be  LR(1).  This  means  that  the  input  token 
stream  will  be  processed  left-to-right  with  a  look  ahead  of  one  input  token.  This 
is  the  simplist  form  of  parser  to  develop. 
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Chapter  2:  SDM  Description 

This  chapter  will  describe,  in  detail,  the  SDM  as  presented  by  Hammer  and 
McLeod  in  reference  [l].  Extensions  to  the  SDM  specification  presented  here  will  be 
introduced  in  Chapter  3.  The  SDML  grammar  definition  will  be  discussed  in 
Chapter  4. 

An  SDM  specification  is  an  organized  grouping  of  entities  which  exist  in  an 
application's  database.  The  structure  of  the  SDM  specification  Is  as  follows: 

•  Entities  are  logically  grouped  into  classes.  Each  class  in  the  SDM  is,  therefore, 
a  logical  collection  of  entities  describing  the  class. 

•  Classes  are  related  by  interclass  connections. 

•  Entities  and  classes  have  attributes.  The  attributes  of  an  entity  or  class  are 
what  actually  provide  the  semantic  integrity  for  the  SDM. 

Consider  the  relational  database  model  where  the  database  is  represented  by  a 
number  of  tables.  Each  table  consists  of  a  number  of  rows  (tuples)  and  columns. 
The  SDM  class  is  synonymous  with  the  relational  database  table.  The  entities  in 
the  SDM  class  represent  the  rows  (tuples)  in  the  relational  database  table.  The 
attributes  of  the  entities  in  the  class  represent  the  relational  database  table 
columns.  Appendix  1  contains  an  example  of  an  SDM  schema.  This  schema 
represents  car  dealerships  and  cars  in  stock  in  each  dealership.  This  schema  will  be 
used  to  support  the  discussion  of  some  of  the  features  of  the  SDM  schema 
throughout  the  rest  of  this  chapter. 


3.1   Classes 

A  class  Is  a  logical  collection  of  entities.  Each  class  in  SDM  can  be  either  a  base 
class  or  a  nonbase  class.  A  base  class  is  one  which  is  defined  independently  of  all 
other  classes  in  the  database.  That  is,  it  is  not  related  In  any  way  to  any  other 
class  in  the  SDM  schema.  Therefore,  base  classes  do  not  have  interclass 
connections.  The  class  CARS  in  Appendix  1  is  an  example  of  a  base  class.  The 
class  CARS  cannot  be  described  in  terms  of  any  other  class  in  the  SDM  schema.  A 
nonbase  class  is  one  which  is  described  in  terms  of  one  or  more  other  classes  in  the 
SDM  schema.  This  relationship  is  defined  with  the  interclass  connection.  For 
example,  the  nonbase  class  BUICKS  is  denned  as  a  subclass  of  the  base  class  CARS. 
The  entities  in  any  nonbase  class,  therefore,  are  dependent  on  the  entities  in  the 
classes  in  which  they  are  based. 

Classes  in  the  SDM  schema  can  represent  any  one  of  the  following  abstractions: 

i.    Concrete  object  such  as  CARS  or  DEALERS. 

il.    Events  such  as  car  preparations  (PREPS). 

ill.    Categorizations  or  aggregations  of  entities. 

iv.    Names  (syntactic  identifiers). 

The  first  three  types  of  classes  represent  definitions  of  base  and  nonbase  classes  and 
will  be  described  in  the  following  sections.  The  last  type  of  class  (name  classes) 
represent  the  data  in  the  SDM  schema  which  is  communicated  with  the  outside 
world  (i.e.,  the  database  user).  The  name  class  defines  the  domain  of  the  data  item 
which  will  be  used  to  enter  data  into  and  retrieve  data  from  the  database.   The 


first  three  types  of  classes  will  define  the  value  class  of  their  attributes  as  one  of 
the  name  classes  defined  elsewhere  in  the  SDM  schema.  Name  classes  will  be 
defined  in  detail  in  section  2.4. 

Each  class  in  the  SDM  schema  has  the  following  features: 

1.  A  class  name,  which  uniquely  identifies  the  class  in  the  SDM  schema. 
Multiple  synonymous  class  names  are  permitted.  Class  names  in  this  paper 
are  represented  by  a  string  of  upper-case  letters  and  special  characters  (e.g., 
CARS  and  BUICKS). 

2.  A  collection  of  members,  which  represent  the  entities  in  the  class.  The 
concept  of  class  members  is  implicit  in  the  definition  of  the  SDM  schema. 
That  is,  class  members  are  not  explicitly  defined  in  the  SDM  schema. 

3.  An  optional  class  description,  which  gives  an  English  language  description  of 
the  class.  The  class  description  allows  for  better  documentation  of  the  SDM 
schema. 

4.  A  collections  of  attributes,  which  describe  the  members  of  the  class  or  the 
class  as  a  whole.  The  two  types  of  attributes  are: 

a.  Member  attributes  describe  a  member  of  a  class  by  logically  associating 
the  class  member  to  one  or  more  entities  in  the  same  or  another  class. 

b.  Class  attributes  describe  the  given  class  as  a  whole.    Attributes  are 
described  in  section  2.3. 

5.  A  base  class  has  a  list  of  identifiers  which  uniquely  identify  a  member  of  a 
class.  Thus,  the  identifiers  serve  as  a  "key"  for  uniquely  identifying  a  specific 
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member  Cor  entity)  of  a  class.    Use  of  identifiers  implies  that  duplicate 
members  are  not  allowed  (see  item  6). 

6.  A  base  class  is  specified  as  either  containing  duplicates  or  not  containing 
duplicates.  This  defines  whether  the  class  can  contain  duplicate  members  or 
not.  The  default  is  that  duplicate  members  are  allowed. 

7.  A  nonbase  class  is  defined  to  be  related  to  one  or  more  other  classes  by 
specification  of  an  interclass  connection.  The  interclass  connection  is 
described  in  the  following  section. 

3.2  Interclass  Connection 

Any  nonbase  class  has  an  interclass  connection  describing  how  the  nonbase  class 
relates  to  other  classes  in  the  database.  Interclass  connections  define  the  entities  in 
a  nonbase  class  by  specifying  a  predicate  P  which,  when  applied  to  the  entities  of 
another  class  C,  yield  the  desired  nonbase  subclass  S.  The  two  types  of  interclass 
connections  are  the  subclass  connection  and  the  grouping  connection. 

3.2.1  Subclass  Connection.  This  type  of  interclass  connection  is  used  to  define  a 
nonbase  class  S  as  a  subclass  of  a  parent  class  C.  Thus,  the  members  of  the 
nonbase  class  S  form  a  subset  of  the  members  of  the  parent  class  C .  The  members 
of  the  subclass  5  are  determined  by  the  definition  of  a  predicate  P  which  is  applied 
to  the  members  of  C .  The  subclass  connection  defines  the  nonbase  subclass  S  as 
consisting  of  all  entities  of  the  parent  class  C  which  satisfy  a  given  predicate  P. 
The  following  sections  describe  the  four  types  of  subclasses  which  can  be  defined 
via  subclass  connections. 
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3.2.1.1  Attribute-Defined  Subclass.  This  type  of  subclass  connection  defines  the 
subclass  S  to  be  all  members  of  C  such  that  the  given  attribute(s),  A,  of  C  satisfy 
a  given  regular  expression  involving  a  value  VA),  of  the  value  class  of  A,.  An 
attribute  predicate  is  used  to  define  this  type  of  subclass  connection.  The  attribute 
predicate  can  be  either  a  simple  predicate: 

where  <At>  =  <VA  >. 
or  a  compound  predicate: 

where  <At>  -  <VAl>  and  <A2>  -  <VAj>. 
Any  of  the  logical  operators  and  scalar  comparators  can  be  used  in  the  attribute 
predicate  where  the  attribute  is  single  valued.  The  attribute  predicate  can  also  be  a 
set  operation: 

where  <AX>  contains  <VA  >, 
where  the  attribute  is  multivalued. 

An  example  of  the  use  of  this  type  of  subclass  connection  is  in  the  definition  of  the 
class  BUICKS  which  is  a  subclass  of  CARS.  The  interclass  connection  for  the 
BUICKS  nonbase  class  would  be 

subclass  of  CASS  where  Make  -  'buick' . 
Here,  the  BUICKS  nonbase  class  is  made  up  of  all  members  of  class  CARS  where 
the  "Make"  attribute  has  a  value  of  'buick'. 

3.2.1.2  User-Controllable  Subclass.  This  type  of  subclass  connection  defines  the 
subclass  S  to  be  any  members  of  the  class  C  as  specified  by  the  database 
administrator.  The  predicate 
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where  specified 
Is  used  to  define  this  type  of  subclass  connection. 

An  example  of  the  use  of  this  type  of  subclass  connection  is  in  the  definition  of  the 
nonbase  class  PREPARED_CARS  which  is  a  subclass  of  CARS.  The  interclass 
connection  for  the  PREPARED_CARS  nonbase  class  would  be 

subclass  of  CARS  where  specified. 
Here,  the  members  of  the  PREPARED_CARS  class  would  be  CARS  which  are 
prepared  for  delivery  (as  specified  by  the  database  administrator). 

3.2.1.3  Set-Operator-Defined  Subclass.  This  type  of  subclass  connection  defines  the 
subclass  S  to  be  any  members  of  C  which  adhere  to  some  set  operation  on  two 
other  database  classes  C,  and  C2.  Possible  set  operations  are  intersection,  union, 
and  difference.  The  classes  C,  and  C2  must  be  subclasses  of  class  C  for  the  set 
operations  to  be  valid.  The  predicates 

is  in  <Ci> 
and 

is  not  in  <Cx> 

are  used  to  define  a  set-operator-defined  subclass. 

An  example  of  the  use  of  this  type  of  subclass  connection  is  in  the  definition  of  the 
nonbase  class  PREPARED_BUICKS,  which  is  a  subclass  of  CARS.  The  interclass 
connection  for  the  PREPARED_BUICKS  nonbase  class  would  be 

subclass  of  CARS  where  is  in  PREPARED_CARS  and  is  in  BUICKS. 
This  interclass  connection  also  describes  the  use  of  the  intersection  set-operator- 
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defined  subclass. 

3.2.1.4  Existence  Subclass.  This  type  of  subclass  connection  defines  the  subclass  S 
to  be  any  members  of  C  which  are  currently  values  of  some  attribute  A  of  another 
class  Ct.  The  predicate 

where  is  a  value  of  A  of  C  x 
is  used  to  specify  a  nonbase  class  S  as  an  existence  subclass  of  C . 

An  example  of  the  use  of  this  type  of  subclass  connection  is  in  the  definition  of  the 
nonbase  class  BUICK_DEALERS,  which  is  a  subclass  of  DEALERS.  The  interclass 
connection  for  the  BUICK_DEALERS  nonbase  class  would  be 

subclass  of  DEALERS  where  is  a  value  of 
Dealership  of  BUICKS . 

3.2.2  Grouping  Connection.  The  grouping  connection  defines  a  nonbase  class  which 

has  members  which  are  classes.  The  nonbase  grouping  class  G  defines  a  class  which 

has  members  which  are  classes  of  the  underlying  class  U .  Thus,  grouping  classes 

are  of  a  higher  order  than  subclasses.  In  the  relational  database  model,  they  would 

be  representational  of  a  table  of  tables.   The  following  sections  describe  the  three 

types  of  grouping  classes  which  can  be  denned  via  the  grouping  connection. 

3.2.2.1  Expression-Defined  Grouping  Class.  This  type  of  grouping  class  allows 
definition  of  a  nonbase  class  G  which  is  made  up  of  all  classes  formed  by  collecting 
the  members  of  the  underlying  class  U  into  classes  based  on  a  common  value  for 
one  or  more  member  attributes  of  U .  The  predicate 

on  common  value  of  <  attribute  > 
is  used  to  specify  this  type  of  grouping  class. 
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Note  that  each  class  in  the  grouping  class  is  also  an  attribute-defined  subclass  of 
the  underlying  class  U.  If  this  attribute-defined  subclass  is  explicitly  defined  in 
the  SDM  schema  elsewhere,  the  qualifier 

groups  defined  as  classes  are  C  t.  C2 C„ 

is  used  to  state  that  this  explicit  nonbase  class  definition  is  already  made.  This 
implies  a  duplicate  class  definition,  one  explicitly  made  in  the  SDM  schema,  and 
one  as  a  class  member  of  a  grouping  class. 

An  example  of  the  use  of  this  grouping  class  is  In  the  definition  of  the  nonbase 
class  CAR_MODELS.  This  class  defines  a  grouping  of  all  of  the  different  car 
models.  The  predicate  used  to  define  CAR_MODELS  is 

grouping  of  CARS  on  common  value  of  Make  and  Model . 
Since  the  attribute-defined  subclass  SOMERSETS  is  denned  explicitly  in  the  SDM 
schema,  the  qualifier 

groups  defined  as  classes  are  SOMERSETS 
is  also  stated. 

3.2.2.2  Enumerated  Grouping  Class.  This  type  of  grouping  class  allows  definition 
of  a  nonbase  class  G  which  is  made  up  of  all  the  given  classes.  Thus,  G  is  defined 

as  a  grouping  of  classes  ClC2 C„ ,  where  each  of  the  classes,  C,- ,  are  subclasses  of 

the  underlying  class  U.  The  predicate 

consisting  of  classes  Cu  C2.  ....  C„ 
is  used  to  define  this  type  of  grouping  class. 
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3.2.2.3  User-Controllable  Grouping  Class.  This  type  of  grouping  class  allows 
definition  of  a  nonbase  class  G  which  is  made  up  of  a  user  defined  number  of 
classes,  each  with  a  user  defined  number  of  members.  The  predicate 

where  specified 
is  used  to  define  this  type  of  grouping  class. 

3.3  Attributes 

Each  class  in  the  SDM  schema  has  a  collection  of  attributes  (representing  the 
columns  in  the  relational  database  model)  describing  the  class.  Attributes  can 
either  describe  the  members  of  a  class  (member  attributes)  or  the  class  itself  (class 
attributes).  A  member  attribute  has  a  value  for  each  member  (or  each  tuple)  of 
the  class.  A  class  attribute  has  only  one  value  for  the  class  as  a  whole 
(independent  of  the  number  of  members  of  the  class). 

Each  attribute  has  the  following  features: 

1.  An  attribute  name  which  uniquely  identifies  the  attribute  within  the  class, 
the  underlying  base  class,  and  all  eventual  subclasses  of  the  underlying  base 
class.  As  with  class  names,  multiple  synonymous  names  are  permitted. 

2.  A  value  which  is  either  an  entity  in  the  database  or  a  collection  of  entities. 
An  attributes  value  class  defines  the  class  which  the  value  comes  from.  An 
attributes  value  can  also  be  null. 

3.  An  optional  attribute  description  is  an  English  language  description  of  the 
attribute.  This  serves  as  a  documentation  tool  in  the  SDM  schema. 
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4.  The  attribute  can  be  either  single  valued  or  multivalued.  The  default  is  single 
valued.  A  single  valued  attribute  defines  the  value  of  the  attribute  as  a 
single  tuple  of  the  value  class.  A  multivalued  attribute  defines  the  value  of 
the  attribute  as  a  collection  of  tuples  of  the  value  class.  Therefore,  the 
multivalued  attribute  is  itself  an  SDM  class. 

A  multivalued  attribute  can  also  have  a  constraint  on  the  size  of  the  class 
(i.e.,  number  of  members)  placed  by  specifying  multivalued  with  size 
between  X  and  Y",  where  X  and  Y  are  integers. 

5.  An  attribute  value  can  be  specified  as  mandatory,  which  means  that  it  cannot 
contain  a  null  value.  The  term  may  not  be  null  is  used  to  specify  a 
mandatory  attribute  value. 

6.  An  attribute  can  be  specified  as  not  changeable.  Here,  once  a  non-null  value 
is  specified  for  an  attribute,  it  cannot  be  changed. 

7.  An  attribute  can  be  specified  to  be  exhaustive  of  its  value  class.  Here,  every 
value  of  the  value  class  must  be  the  attribute  value  of  some  entity  in  the 
class.  The  phrase  exhausts  value  class  is  used  to  specify  this  feature. 

8.  A  multivalued  attribute  can  be  specified  as  having  nonoverlapping  values. 
This  means  that  no  two  values  of  the  attribute  have  any  entities  (tuples)  in 
common.  The  term  no  overlap  in  values  is  used  to  specify  nonoverlapping 
values. 

9.  An  attribute  can  be  related  to  other  attributes  In  the  SDM  schema  with 
attribute  relationships.  These  attribute  relationships  are  described  in  the 
following  sections. 
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3.3.1  Attribute  Mappings.  Attribute  mappings  provide  a  mechanism  of  directly 
referencing  an  attribute  within  the  value  class  of  an  attribute.  An  attribute 
mapping  is  specified  by  listing  each  attribute  in  the  sequence  separated  by  periods. 
An  example  of  an  attribute  mapping  is  when  referencing  the  name  of  a  dealership 
for  cars.  Here,  the  attribute  mapping  "Dealership.Name"  references  the  "Name" 
attribute  for  the  DEALERS  class,  which  is  the  value  class  for  the  "Dealerships" 
attribute  of  the  CARS  class.  Thus,  "Dealership.Name"  gives  the  dealership  name 
for  the  given  car. 

Formally,  an  attribute  mapping  is  a  sequence  of  attributes,  Nt  denned  within 
classes  C,  respectively  (iV^j.  ■  •  •  JVm)  where  the  value  class  of  N,  is  C,+1  for  all 
i  =  l....jn  —  1. 

The  following  rules  apply  to  attribute  mappings: 

i.    An  attribute  mapping  AM  is  multivalued  if  any  one  of  the  attributes  N,  is 
multivalued. 

ii.    the  value  class  of  the  attribute  mapping  AM  is  the  value  class  of  the  last 
attribute  Nm  in  the  mapping  (i.e.,  class  Cm ). 

3.3.2  Attribute  Inheritance.  When  defining  a  subclass  S  of  a  class  C,  the 
attributes  of  class  C  are  inherited  by  the  subclass  S  according  to  the  following 
rules: 

1.  A  class  S   denned  as  an  attribute-defined  subclass  or  a  user-controllable 
subclass  of  a  parent  class  C  inherits  all  of  the  member  attributes  of  C . 

2.  A  class  S  denned  as  an  intersection  subclass  of  classes  C^  and  C2  inherits  all 
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of  the  member  attributes  of  both  classes  Ci  and  C2. 

3.  A  class  S  denned  as  a  union  subclass  of  classes  Ci  and  C2  inherits  all  of  the 
member  attributes  common  to  C^  and  C2. 

4.  A  class  S  denned  as  a  difference  subclass  of  classes  C  and  C  i  (i.e.,  members 
of  class  C  not  in  class  C  i)  inherits  all  of  the  member  attributes  of  class  C . 

Member  attributes  inherited  by  a  subclass  are  not  explicitly  defined,  but  are 
assumed  based  on  how  the  subclass  is  denned  (by  the  above  rules).  One  can, 
however,  place  constraints  on  the  value  class  of  an  inherited  member  attribute  by 
explicitly  specifying  the  inherited  member  attribute  in  the  subclass  definition  with 
the  new  value  class  specification.  An  example  of  this  is  in  the  specification  of  the 
subclass  BUICKS  of  class  CARS.  Here,  an  additional  constraint  is  put  on  the 
inherited  member  attribute  "Model"  of  the  BUICK  subclass.  The  constraint  is  that 
the  "Model"  attribute  of  class  BUICKS  can  only  be  from  the  value  class 
BUICK_MODELS  (instead  of  the  inherited  value  class  CAR_MODELS). 

3.3.3  Member  Attribute  Interrelationships.  Member  attribute  interrelationships 
allow  member  attributes  of  two  or  more  classes  to  be  related  in  the  SDM  schema. 
The  three  types  of  member  attribute  interrelationships  are  the  inverse,  the  match, 
and  the  derivation.  The  inverse  and  matching  interrelationships  are  described  here. 
The  derivation  is  described  in  the  next  section.  Formal  definitions  are  also  given 
for  the  inverse  and  matching  interrelationships,  since  they  may  be  easier  to 
comprehend  then  the  engllsh  definition. 

The  first  member  attribute  interrelationship  is  the  inverse  relationship.  The 
inverse  relationship  defines  a  symmetrical  relationship  between  two  attributes  of 
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two  classes.  Consider  classes  Cx  and  C2,  with  attributes  At  and  A2  respectively. 
Member  attribute  A,  of  C,  is  denned  as  the  inverse  of  attribute  A2  of  C2  if  the 
value  of  .4,  for  a  member  Mt  of  Ct  consists  of  those  members  of  C2  whose  value 
of  A  2  is  Mi.  Since  inversion  establishes  a  symmetrical  relationship,  attribute  A  2  of 
C2  is  also  denned  as  the  inverse  of  attribute  A  i  or  C2  in  the  SDM  schema. 

Formally,  the  value  of  AY  for  member  M,  of  class  Cj  is  denned  in  terms  of 
attribute  A2  of  class  C2  as  follows: 

A  !  of  M i  ■  members  of  C2  such  that  Af  t  e  A  2 
The  SDM  schema  segment  in  Figure  3-1  describes  how  the  inverse  relationship 
would  be  described  in  an  SDM  schema.    The  value  class  restrictions  are  also 
displayed. 


C, 

member  attributes: 
Ax 

value  class:  C2 
inverse:  A  2 


C2 

member  attributes: 
A2 

value  class:  C  i 
inverse:  A  i 

Figure  3-1.  SDM  Inverse  Attribute  Relationship 

Operationally,  the  inverse  works  as  follows.   When  class  Cj  (or  C2)  is  changed  in 

some  way  (i.e.,  member  record  added,  deleted,  updated,  etc.),  the  corresponding 

appropriate  will  be  made  to  members  of  class  C2  (or  Cj.    Thus,  the  inverse 

relationship  ensures  that  the  two  attributes  remain  consistently  defined  throughout 

the  life  of  the  database. 
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An  example  of  the  inverse  relationship  is  that  of  the  attribute  "Dealership"  of  class 
CARS  and  attribute  "Cars_in_stock"  of  class  DEALERS.  Here,  the  value  of  the 
"Dealership"  attribute  of  a  car  is  those  DEALERS  whose  "Cars_in_stock"  contain 
the  given  car.  Also,  the  value  of  the  "Cars_in_stock"  for  a  dealer  contain  those 
members  of  CARS  which  have  a  "Dealership"  attribute  value  of  the  given 
dealership.  The  inverse  relationship  would  ensure  that  the  "Cars_in_stock" 
attribute  of  DEALERS  is  updated  automatically  when  members  are  added  to  class 
CARS  which  specify  the  appropriate  value  of  the  "Dealership"  attribute. 

The  second  attribute  interrelationship  is  the  matching  relationship.  The  value  of 
the  match  attribute  A !  for  the  member  Mt  of  class  Cx  is  determined  as  follows: 

a.  A  member  M2  of  some  class  C2  is  determined  such  that  C2  has  M ^  as  its 
value  of  member  attribute  A  2. 

b.  The  value  of  member  attribute  A  for  M  2  is  used  as  the  value  of  A !  for  it j. 

The  matching  relationship  is  specified  in  the  SDM  schema  as  shown  in  Figure  3-2. 
C 


member  attributes: 

At 

value  class:  C ! 

match:  A  of  C2 

on<42 

2 

member  attributes: 

A2 

value  class:  C 

A 

value  class:  Cj 

Figure  3-2.  SDM  Attribute  Matching  Relationship 
Formally,  the  value  of  the  A!  attribute  for  member  Aft  of  class  Cx  is  determined 
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from  attributes  A  and  A2,  and  member  M 2  of  class  C2  as  follows: 

A  i  of  Mi  =  A  of  M2  mC2  such  that  A*!  e  A2  in  Af2 
The  matching  attribute,  therefore,  automatically  derives  the  value  of  attribute  A  i 
of  class  Ci  from  the  given  information.    This  implies  that  the  attribute  Ai  can 
never  be  given  a  value  directly  by  the  user. 

An  example  of  the  use  of  the  matching  relationship  is  in  the  definition  of  the 
"Owner"  attribute  of  the  CARS  class.  Here,  the  owner  of  a  car  is  the  same  as  the 
owner  of  the  dealership  where  the  car  is  in  stock.  To  specify  this  relationship,  the 
"Owner"  attribute  of  a  car  is  defined  to  be  the  "Owned_by"  attribute  value  for  the 
member  of  DEALERS  which  has  this  car  as  a  value  of  "Cars_in_stock".  Notice 
that  the  class  of  "Owners"  of  class  CARS  and  "Owned_by"  of  class  DEALERS  must 
be  the  same. 

3.3.3.1  Member  Attribute  Derivations.  The  third  and  last  type  of  member 
attribute  interrelationship  is  the  derivation.  The  derivation  is  used  to  define  an 
attribute  as  being  derived  Cor  calculated)  from  other  attributes  in  the  SDM  schema. 
A  number  of  derivation  primitives  are  supported  by  the  SDM.  Each  derivation 
primitive  supplies  a  mechanism  for  computing  a  derived  attribute.  Combined  use 
of  these  derivation  primitives  can  lead  to  the  development  of  arbitrarily  complex 
derivations. 

A  description  of  all  the  derivation  primitives  supported  by  SDM  follows.  The 
descriptions  involve  the  definition  of  a  derived  attribute  At  of  class  Ct  with 
member  Mi. 

1.    A  i  can  be  defined  as  an  ordering  attribute.  Here,  the  value  of  attribute  A  j  is 


-21- 


the  sequential  position  of  M,  within  Cl  when  the  members  of  Ct  are  ordered 
by  other  specified  attributes  of  Cx.  Members  of  Ci  can  be  ordered  by 
increasing  (default)  or  decreasing  value.  The  phrase 

order  by  A  2 
is  used  to  define  an  ordering  derivation.  Ordering  of  the  members  M,  of 
class  Ci  can  also  be  specified  in  groups  based  on  another  attribute  A3  of  C%. 
Here,  the  value  of  A  i  is  the  sequential  position  of  member  Mx  within  the 
group  of  members  of  Ct  which  have  a  common  value  of  attribute  A3.  The 
phrase 

order  by  A  2  within  A  3 
is  used  to  specify  ordering  withing  groups. 

2.  A !  can  be  defined  as  an  existence  attribute.  Here,  A  t  contains  the  value  "yes" 
if  member  M i  of  Ci  is  a  member  of  some  other  specified  class  C2,  and  "no" 
otherwise.  The  phrase 

if  in  C2 
is  used  to  define  an  existence  attribute. 

3.  A !  can  be  defined  by  recursively  tracing  the  values  of  some  attribute  A2. 
The  value  class  of  A  2  must  be  the  same  as  the  value  class  of  A  t.  The  phrase 

all  levels  of  values  of  A  2 
is  used  to  define  this  type  of  attribute  derivation.   This  attribute  derivation 
can  also  specify  a  limit  to  the  number  of  recursions  of  tracing  the  values  of 
A  2.  The  phrase 


■22 


up  to  n  levels  of  values  of  A  2 
is  used  to  place  a  restriction  of  n  levels  on  the  recursive  tracing  of  attribute 

A2. 

4.  The  derived  multivalued  member  attribute  Contents  is  automatically  defined 
when  a  grouping  class  is  denned.  This  member  attribute  has  a  value 
representing  the  contents  of  each  class  underlying  the  grouping  class.  That 
is,  each  value  of  "Contents"  represents  all  of  the  members  of  one  of  the 
classes  underlying  the  grouping  class. 

5.  A !  can  be  denned  to  be  directly  derived  from  another  attribute  A  2.  Here, 
whatever  value  is  given  to  attribute  A2  is  also  given  to  attribute  At.  The 
description 

same  as  A  2 
is  used  to  define  this  type  of  derivation. 

6.  Ai  can  be  denned  as  a  subvalue  of  some  other  attribute  A2  which  satisfies 
some  predicate  P.  The  predicate,  P,  can  be  any  of  the  attribute  predicates 
denned  in  section  2.2.1.  The  description 

subvalue  of  A  2  where  P 
is  used  to  define  a  subvalue  attribute.   Predicate  P  may  contain  mappings 
which  are  used  to  determine  which  values  of  A2  are  applicable.    These 
mappings,  however,  must  be  consistent  with  the  value  class  of  attribute  A2. 

7.  A  i  can  be  defined  as  the  intersection,  union,  or  difference  of  two  other 
multivalued  attributes.  A  union  derivation  would  be  specified  as 
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where  is  in  A  2  or  is  in  A  3. 

8.  A  i  can  be  denned  In  terms  of  other  attributes  with  an  arithmetic  expression. 
All  of  the  attributes  involved  in  the  arithmetic  expression  must  have  a  value 
class  of  the  built  in  class  NUMBERS.  The  set  of  possible  arithmetic 
operators  are  addition  ("+"),  subtraction  ("-"),  multiplication  ("*"),  division 
("/"),  and  exponentiation  ("!"). 

9.  A !  can  be  denned  to  be  the  "minimum",  "maximum",  "average",  or  "sum"  of 
another  multivalued  attribute.  The  denning  attribute  must  have  a  value 
class  of  the  built  in  class  NUMBERS. 

10.  A !  can  be  denned  to  be  the  number  of  members  in  some  other  multivalued 
attribute  A  2.  The  phrase 

number  of  members  in  A  2 
is  used  to  specify  this  derivation.   The  user  can  also  specify  that  A ,  be  the 
number  of  unique  members  of  attribute  A2.  The  number  of  unique  members 
differs  from  the  number  of  members  only  when  duplicates  are  present  in  the 
attribute  A  2. 

3.3.3.2  Member  Attribute  Definition  Rules.  Hammer  and  McLeod  describe  how  the 
use  of  derivation  specifications  must  be  used  to  avoid  inconsistent  attribute 
specifications.  Every  attribute,  A  u  satisfies  one  of  the  following  cases: 

a.  A ,  has  exactly  one  derivation.  Here,  the  value  of  A ,  is  completely  specified 
by  the  derivation.  If  an  inverse  of  A  t  exists,  it  may  not  have  a  derivation  or 
a  matching  specification. 
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b.  A,  has  exactly  one  matching  specification.  Here,  the  value  of  A,  is 
completely  specified  by  its  relationships  with  an  entity  (or  entities)  to  which 
It  is  matched.  If  an  inverse  of  At  exists,  it  may  not  have  a  derivation.  The 
inverse  of  At  can,  however,  have  a  matching  specification,  but  must  be 
consistent  with  the  matching  specification  of  A  t. 

c.  A  j  has  neither  a  matching  specification  nor  a  derivation.  Here,  it  may  be  the 
case  that  the  inverse  of  A  i  has  a  matching  specification  or  a  derivation.  If 
this  is  the  case,  one  of  the  above  two  cases  applies.  Otherwise,  A  t  and  A , 
form  a  pair  of  primitive  values  that  are  denned  in  terms  of  one  another,  but 
which  are  independent  of  all  other  information  In  the  database. 

The  concept  of  defining  an  inverse  and  a  matching  relationship  within  the  same 
attribute  definition  warrants  some  discussion.  Recall  from  the  discussions  of  the 
Inverse  and  matching  attribute  interrelationships,  the  operation  of  the  two  types  of 
relationships.  Inverse  supplies  an  automatic  update  mechanism  for  one  attribute 
when  the  other  corresponding  attribute  is  modified.  Matching  supplies  an 
automatic  derivation  of  an  attribute  from  other  information  in  the  database. 
Consider  an  attribute  Ay  defined  in  class  Cx  with  both  an  inverse  and  matching 
attribute  interrelationship  denned  as  shown  in  Figure  3-3. 
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c, 

Ax 

value  class:  C2 

inverse:  A  3 

match:  A  oi  C3oaA2 


C2 
A3 

value  class:  C 1 
inverse:  .A  j 


C3 

value  class:  C2 
value  class:  C ! 


Figure  3-3.  Combined  Use  of  Match  and  Inverse  Attribute  Interrelationships 
The  inverse  relationship  between  A^  and  A3  means  that  whenever  one  of  the  two 
attributes  is  changed,  the  other  one  is  changed  appropriately.  The  match 
relationship  for  A ,  means  that  A  t  cannot  ever  be  directly  assigned  a  value,  but  is 
automatically  derived  from  attributes  A  and  A2  in  class  C3.  This  implies  an 
indirect  dependence  of  A3  of  class  C2  on  attributes  A  and  A  2  in  class  C3.  If  this 
dependence  were  not  recognized  by  the  model,  a  change  to  attribute  A3  for  class  C2 
would  initiate  a  corresponding  change  to  attribute  Ax  for  class  d-  This  could 
invalidate  the  matching  relationship  between  attribute  4,  and  the  attributes  in 
class  C3.  Therefore,  when  a  matching  relationship  is  denned  within  an  attribute 
definition,  and  an  inverse  relationship  also  exists,  a  matching  relationship  is  also 
assumed  for  the  Inverse  attribute  (here  A3\  Further,  if  the  database  designer 
specifies  a  matching  relationship  for  the  inverse  attribute,  it  had  better  be  the 
matching  relationship  which  is  assumed. 
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The  matching  relationship  which  is  assumed  for  A  3  is 

match:  A2ofC3onA 
To  see  this  (and  In  fact  to  conceptualize  the  inverse/match  combined  definition),  an 
example  will  be  given.  Referring  to  Figure  3-3,  consider  the  following  notation: 

i.    M,  '  will  represent  member  i  of  class  C, . 

11.  M,  '(At  M^.-l  means  that  the  *a  attribute  of  member  Mf>  contains  the 
members  M. ,  etc..  from  class  C, .  Note  that  this  implies  that  the  value  class 
of  At  is  C, . 

Figure  3-4  shows  a  derivation  for  the  attributes  A ,  and  A3  based  on  the  values  of 
A  and  A2  in  class  C2.  First,  given  the  values  for  A  and  A2  for  members  M?>  and 
Ma>  of  class  C3,  and  using  the  formal  definition  for  matching,  we  can  attempt  to 
derive  the  A,  values  for  all  members  of  class  Ct.  Given  only  the  two  specified 
members  of  class  C3,  only  the  A ,  attribute  for  member  Mp  Is  derivable  since  this 
is  the  only  member  of  C,  which  appears  as  a  member  of  the  A  attribute  of  C3. 
Using  the  formal  definition  of  matching,  the  At  attribute  for  member  iff"  is  the 
two  members  M2>  and  A#  of  class  C2  (which  is  the  value  class  of  A  J.  Now 
applying  the  inverse  relationship  between  A ,  and  4„  we  can  attempt  to  derive  the 
43  attribute  value  for  all  members  of  class  C2.  Using  the  formal  definition  for 
inverse,  members  Mc2'  and  AfJ»  both  have  M?>  as  their  value  (note  that  C,  is  the 
value  class  of  A3,  which  is  consistent  with  the  definition).  Now,  it  can  be  seen  that 
using  the  assumed  matching  definition  for  attribute  A3,  the  values  derived  for  A, 
using  the  inverse  with  A,  are  exactly  the  same  as  the  matching  relationship 
between  A  3  and  attributes  A  and  A  2  of  class  C3. 
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C,: 


M,1  (A,:?) 


M"h>(A3 
MS  (A} 

m\'{a3 


?) 

Mc,n 

Mi1) 

?) 


m{'  (A  :Mc2>A2:MCl1') 

M,'  (A  :?A2:7) 

M2'  {A  :M3:>A2:M'i') 

Figure  3-4.  Example  of  Match/Inverse  Combined  Derivation 

This  example  is  by  no  means  a  proof  of  the  assumed  matching  relationship,  but 

only  shows  how  the  assumed  matching  relationship  logically  fits  in  with  the 

inverse  and  matching  relationships  explicitly  denned. 

3.3.4  Class  Attribute  Derivations.  Attribute  derivation  primitives  analogous  to 
those  listed  in  items  5  through  10  in  the  previous  section  can  be  used  to  define 
class  attribute  derivations.  Instead  of  using  other  member  attributes  to  derive  the 
member  attribute,  other  class  attributes  are  used  to  derive  the  class  attribute.  In 
addition  to  items  5  through  10  of  the  previous  section,  two  additional  primitives 
can  be  used  to  derive  a  class  attribute: 

1.  The  class  attribute  can  be  defined  to  be  the  number  of  members  in  the  class 
in  which  it  resides.  The  phrase 

number  of  members  in  this  class 
is  used  to  define  this  type  of  class  attribute  derivation. 

2.  The  class  attribute  can   be  denned  to   be  the  "minimum",   "maximum", 
"average",  or  "sum"  of  one  of  the  member  attributes  in  the  class  in  which  it 

-28- 


resides.  The  phrase 

sum  of  A  over  members  of  this  class 
is  an  example  of  this  type  of  class  attribute  derivation. 

3.4  Name  Classes 

Name  classes  define  the  domain  of  the  data  which  is  used  to  communicate  -with  the 
outside  world;  that  is,  the  data  which  can  be  entered  by  a  user  and  which  is 
supplied  to  the  user  as  a  response  to  queries,  etc.  A  name  class  in  SDM  is  a 
subclass  of  one  of  the  built-in  classes,  formed  by  application  of  some  predicate,  P, 
to  to  the  built-in  class.  The  predicates  which  can  be  used  to  define  a  name  class  are 
as  follows: 

1.  The  name  class  can  be  defined  as  a  subclass  of  a  built-in  class.  Here,  all  legal 
members  of  the  built-in  class  can  be  entered. 

2.  The  name  class  can  be  defined  as  a  subclass  of  a  built-in  class,  where 
specified  by  the  database  administrator.  Here,  the  members  of  the  name 
class  are  those  members  of  the  built-in  class  which  are  specified  by  the 
database  administrator. 

3.  The  name  class  can  be  defined  as  a  subclass  of  STRINGS  which  follows  some 
specified  format.  Here,  the  name  class  is  defined  as  all  members  of  STRINGS 
which  satisfy  some  data  format  directive  which  is  specified  in  the  SDM 
schema.  This  name  class  represents  a  class  of  STRINGS  which  satisfy  the 
format  directive;  it  will  not  actually  have  every  member  of  STRING 
satisfying  the  format  directive.  The  next  section  details  the  use  of  the 
format  directive,  F ,  when  used  in  this  type  of  name  class  definition. 
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3.4.1  Format  Directives  The  format  directive  is  defined  in  terms  of  the  Domain 
Definition  Language  (DDL)  as  detailed  in  reference  [13].  DDL  was  created  to  allow 
a  relational  database  model  to  specify  the  semantics  of  the  data  which  it 
represented.  In  the  SDM  schema,  DDL  is  used  to  specify  the  format  directive,  F, 
used  in  the  subclass  interclass  connection  when  denning  a  name  class.  The  format 
directive  (as  in  the  domain  definition  of  reference  [13]),  establishes  the  domain  of 
the  name  class  when  it  is  denned  in  the  SDM  schema;  that  is,  the  domain  of  the 
name  classes  are  static  (do  not  change). 

McLeod  defined  a  domain  definition  to  consist  of  four  parts:  (1)  domain  name,  (2) 
domain  description  (establishing  the  domain),  (3)  ordering  of  the  domain  values, 
and  (4)  a  violation-action  to  be  taken  if  the  domain  description  is  violated.  In  the 
SDM  schema,  the  domain  name  will  be  the  class  name  of  the  name  class.  The 
domain  description  will  be  for  format  directive  in  the  name  class.  Also,  as  part  of 
the  format  directive,  the  ordering  of  the  domain  values  defined  in  the  domain 
description  will  be  supplied. 

A  domain  description  is  specified  by  any  one  (or  a  combination  of)  the  following: 

a.  decomposing  the  domain  values  into  submits  which  restrict  the  domain 
values  for  the  name  class  by  specifying  a  format  for  the  data, 

b.  enumerating  the  domain  values;  that  is,  specifying  that  the  domain  consists 
of  a  finite  number  of  values  (note  that  the  enumeration  of  the  domain  values 
is  done  at  the  subunit  level  in  the  format  directive), 

c.  placing  restrictions  on  the  set  of  domain  values  by  definition  of  a  predicate, 
p ,  which  limits  the  set  of  domain  values. 
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The  format  directive  can  also  be  a  number  of  alternative  domain  decompositions  or 
enumerations  for  the  domain  of  the  name  class.  Each  subunit  specification  can  be 
prefixed  with  a  label  which  allows  reference  to  the  value  of  the  subunit  within  the 
predicate  p . 

The  format  directive  can  specify  that  the  subuntts  denned  be  ordered  by  some 
criteria.  The  possible  ordering  alternatives  are  as  follows: 

1.    list  of  subunits  which  define  the  ordering  precedence  for  the  domain  value 
when  compared, 

ii.  no  ordering  ("none")  which  implies  that  only  equality  comparators  are 
possible, 

hi.  atomic  ordering;  that  is,  the  when  the  domain  value  is  compared,  numeric 
ordering  is  used  for  real  numbers  and  lexicographic  ordering  is  used  for 
character  strings. 

A  domain  violation  action  can  be  supplied  to  determine  a  course  of  action  if  data  is 
entered  by  the  user  which  does  not  satisfy  the  given  format  directive.  The  DDL 
presented  in  reference  [13]  provides  three  basic  domain  violation  actions: 

1.  flag  an  error  and  supply  an  optional  message, 

2.  substitute  a  known  value  for  the  value  in  error,  or 

3.  call  a  user-defined  procedure  to  handle  the  error. 

The  basic  format  of  a  format  directive  for  an  interclass  connection  of  a  name  class 
is  shown  in  Figure  3-5. 
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subclass  of  STRINGS  where  format  is 
[label  ia  :  ]  subunit  la 
[label^:  ]  subunit ^ 


[label  lb :  ]  subunit  ib 
[labels :  ]  subunit ^ 

'.] 

[where  p  ] 

[ordering:  ordering-spec] 

[violation  action:  violation-action-spec] 

Figure  3-5.  SDM  Format  Directive  Specification 

An  example  of  the  use  of  the  format  directive  In  the  definition  of  name  classes  is  In 

the  definition  of  the  name  class  VIN_CODES  In  Appendix  1.   The  exact  syntax  of 

the  format  directive  will  be  detailed  in  Chapter  4. 

3.5  Built-in  Classes 

For  convenience,  SDM  provides  some  built-in  class  definitions.  The  built-in  classes 
provided  by  SDM  are  as  follows: 

YES/NO    This  class  has  the  two  members  "yes"  and  "no".    This  provides  the 
boolean  class  definition. 

REALS      This  class  has  members  representing  all  real  numbers. 

INTEGERS  This   class   has   members   representing   all   integers   (positive   and 
negative). 

NUMBERS  This  class  has  members  representing  all  members  of  the  REALS  and 
INTEGERS  classes. 
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STRINGS  This  class  has  members  representing  all  possible  strings  of  characters. 
3.6  Summary 

This  chapter  has  detailed  the  SDM  as  Introduced  by  Hammer  and  McLeod  in 
reference  [l].  Chapter  3  will  introduce  extensions  to  the  SDM  which  will  provide 
greater  capabilities  as  well  as  provide  more  semantic  integrity  into  the  SDM 
described  in  this  chapter.  Chapter  4  will  introduce  the  reader  to  formal  language 
theory  and  present  the  SDML  grammar.  Finally,  Chapter  5  will  discuss  parsing  of 
the  SDML  grammar  and  include  a  discussion  of  the  semantic  checks  which  should 
be  made  in  the  SDML  parser  which  would  not  be  caught  in  the  SDML  grammar 
itself. 
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Chapter  3:  SDM  Extensions 

This  chapter  describes  the  extensions  to  the  SDM  model  which  are  included  in  the 
SDML  grammar  presented  in  Chapter  4.  Since  the  SDM  has  been  used  In  classroom 
study  for  some  time,  the  SDML  grammar  was  designed  to  be  as  syntactically  close 
as  possible  to  the  SDM  presented  in  Chapter  2.  The  two  major  changes  to  the  SDM 
are: 

1.  Description  text  in  SDML  is  enclosed  in  curly-brackets.  This  is  necessary  to 
be  able  to  recognize  the  end  of  the  description  (since  any  character  or 
reserved  words  may  appear  in  the  description). 

2.  The  equality  predicate  (item  9  in  section  2.3.3.1)  and  the  set-order-derived 
predicate  (item  10  in  section  2.3.3.1)  were  combined  to  form  an  enhanced 
equality  predicate.  The  equality  predicate  allowed  an  arithmetic  expression 
involving  attribute  mappings  but  did  not  allow  set  operators  on  multivalued 
attribute  mappings.  The  set-order-derived  predicate  allowed  a  single  set 
operator  to  be  applied  to  a  multivalued  attribute  mapping.  SDML  will 
allow  an  arithmetic  expression  involving  attribute  mappings  and  set 
operators  on  multivalued  attribute  mappings.  Note  that  a  simple  equality 
predicate  involving  a  single  set  operator  on  a  multivalued  attribute  is 
exactly  the  set-order-derived  predicate.  Thus  the  reason  for  the  merging  of 
the  equality  predicate  and  the  set-order-derived  predicate. 

Appendix  2  contains  the  structure  of  an  SDML  specification  in  a  informal  syntactic 
format.  This  structure  specification  is  provided  to  allow  the  reader  to  gain  a 
general    understanding   of    the   structure   of   an    SDML   specification    without 
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attempting  to  follow  the  BNF  specification. 

The  DDL  presented  In  reference  [13]  was  also  included  into  the  SDML  grammar 
with  some  modifications.  Reference  [13]  presented  a  BNF  notation  for  the  DDL. 
The  BNF  listed,  however,  included  some  constructs  which  resulted  in  a  non-LRU) 
grammar.  Therefore,  some  additional  syntax  was  added  to  the  DDL  which  made  it 
LRCl).  Changes  to  the  DDL  will  be  noted  in  the  next  Chapter  as  the  BNF  for  the 
DDL  within  SDML  is  presented. 

The  following  sections  describe  some  extensions  which,  when  added  to  the  SDM 
described  In  Chapter  2,  will  add  some  additional  capabilities.  Appendix  3  contains 
the  structure  of  the  DDL  included  in  SDML. 

4.1   Assertions 

Assertions  will  allow  the  SDM  designer  to  include  statements  of  fact  about  the 
database  being  modeled.  An  assertion  is  a  statement  of  fact  which  should  always 
remain  true  Independent  of  the  state  of  the  database.  If  the  database  enters  a  state 
such  that  the  assertion  Is  no  longer  true,  the  data  In  the  database  is  in  error.  An 
assertion  failure  action  is  supplied  to  indicate  the  action  necessary  when  the 
corresponding  assertion  falls.  These  assertions  are  considered  run-time  assertions 
which  will  flag  invalid  database  states  during  actual  database  use.  Any  number  of 
assertions  can  be  defined  in  the  SDM  schema. 

Three  types  of  assertions  are  supplied  to  the  SDM  designer: 

•  Member  Attribute  Assertions, 

•  Class  Attribute  Assertions,  and 
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•  Interclass  Assertions. 
With  each  of  the  three  types  of  assertions  comes  a  choice  of  three  failure  actions: 

1.  Flag  the  database  state  as  an  error  state  and  optionally  print  a  message 
about  the  condition. 

2.  Warn  the  database  administrator  about  the  condition  with  a  message. 

3.  Call  a  user-denned  procedure  which  will  take  the  appropriate  action.  This 
alternative  allows  the  database  designer  to  build  in  notifications  when 
certain  data  values  in  the  database  obtain  specified  values.  The  optional 
error  message  is  not  supplied  on  this  option  since  the  user-defined  procedure 
should  supply  any  failure  messages  necessary. 

A  failure  action  of  error  is  assumed  if  no  failure  action  is  given  for  the  assertion. 

A  third  failure  action  could  also  be  supplied  which  would  allow  the  database 
designer  to  Indicate  how  the  database  should  be  automatically  repaired  when  the 
assertion  falls.  For  example,  a  member  attribute  assertion  failure  action  could  be 
supplied  such  that  the  member  attribute  value  is  substituted  with  a  derived 
MEMBER_ATTRIBUTE_DERIVATION  (see  Appendix  2).  A  class  attribute 
assertion  failure  action  could  Indicate  that  the  class  attribute  value  is  substituted 
with  a  derived  CLASS_ATTRIBUTE_DERrVATION  (see  Appendix  2).  Finally,  an 
interclass  assertion  failure  action  could  be  supplied  such  that  the  class  is  re- 
populated  using  some  other  interclass  connection.  More  sophisticated  automatic 
repair  specifications  could  be  employed  to  detect  the  source  of  the  problem  and 
correct  any  other  attributes  which  are  found  in  error.  Automatic  database  repair 
specifications  within  an  SDML  specification  will  not  be  dealt  with  here  since  they 
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lend  themselves  to  much  more  study  then  could  be  supplied  in  this  paper.  They 
are,  however,  a  possible  topic  for  further  research. 

The  automatic  repair  of  an  invalid  database  state  could  also  be  thought  of  as  a 
function  of  the  user-defined  procedure.  This  way,  the  procedure  specified  would  be 
responsible  for  detecting  the  source  of  the  error,  correcting  the  error,  and  re- 
verifying  the  state  of  the  corrected  database. 

4.1.1  Member  Attribute  Assertions  Member  attribute  assertions  assert  something 
about  the  value  of  the  given  member  attribute  in  terms  of  other  member 
attributes,  class  attributes  for  that  class,  or  constants.  The  member  attribute 
assertion  can  either 

1.  specify  an  arithmetic  expression  which  should  always  evaluate  to  "true" 
independent  of  the  current  database  state,  or 

2.  specify  a  procedure  to  call  to  provide  the  necessary  assertion  checking. 

The  second  type  of  assertion  allows  the  database  designer  to  indicate  that  the 
attribute  value  must  be  checked  in  a  non-trivial  manner  which  can  be  described  by 
a  procedure  interface. 

An  example  of  the  use  of  the  first  type  of  member  attribute  assertion  is  asserting 
that  the  Date_of_preparation  attribute  of  class  SCHEDULED_PREPS  is  always  =S 
CURRENT.DATE.  The  CURRENT_DATE  used  here  is  another  extension  of  the 
SDM  schema  and  is  presented  in  section  4.3.  This  also  demonstrates  the  use  of  the 
attribute  assertion  to  notify  the  database  administrator  when  the  value  of  an 
attribute  takes  on  some  specified  values  or  exceeds  some  specified  range  of  values. 
This  example  illustrates  the  use  of  the  so  called  notification-assertion  by  notifying 
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the  database  administrator  when  a  car  is  past  due  for  preparation.  This  database 
state  is  not  actually  in  error,  but  requires  some  further  action  on  the  record  to 
resolve  the  conflict  (e.g.,  either  to  change  the  preparation  date  or  to  prepare  the  car 
for  delivery  and  move  the  record  to  PREPARED_CARS  class).  The 
Date_of_preparation  member  attribute  of  class  SCHEDULED_PREPS  Here  the 
assertion 

assertion:        Preparation_date  <  CURRENT_DATE 
failure  action:  call  _notify_past_due 

is  given  within  the  member  attribute  "Date_of_preparation"  of  class 
SCHEDULED_PREPS. 

An  example  of  the  second  type  of  member  attribute  assertion  occurs  when 
specifying  an  interior  color  for  a  car.  Typically,  only  certain  interior  colors  can  be 
used  based  on  the  exterior  color  of  the  car.  Since  the  selection  of  interior  colors 
based  on  the  exterior  color  is  non-trivial,  an  assertion  can  be  supplied  to  verify  the 
choice  of  interior  colors  based  on  the  exterior  color.  Here  the  assertion 

assertion:        call  _verify_interior_color 

failure  action:  error  'invalid  exterior/interior  combination' 

is  given  within  the  member  attribute  "Interior_color"  of  class  CARS  to  show  this 

relationship  between  interior  and  exterior  colors. 

4.1.2  Class  Attribute  Assertions  Class  attribute  assertions  assert  something  about 
the  value  of  the  given  class  attribute  in  terms  of  other  class  attributes,  member 
attributes  within  that  class,  or  constants.  As  with  member  attribute  assertions, 
the  assertion  can  either  specify  an  arithmetic  expression  which  should  evaluate  to 
"true"  independent  of  the  current  database  state,  or  provide  a  procedure  call  which 
verifies  the  current  database  state. 
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An  example  of  the  use  of  the  class  attribute  assertion  is  asserting  that  the 
Number_of_cars_sold  attribute  of  class  CARS_SOLD  is  exactly  equal  to  the 
number  of  members  in  class  SCHF.DULED_PRF.PS  plus  the  number  of  members  in 
class  PREPARED_CARS.  Figure  4-1  shows  how  the  class  definition  of 
CARS_SOLD  would  be  denned  to  show  this  assertion.  The  sizeof  class  operator  is 
another  extension  to  the  SDM  schema  and  is  presented  in  section  4.4. 

4.1.3  Interclass  Assertions  Interclass  assertions  assert  something  about  the 
interclass  connection  for  a  nonbase  class.  This  is  used  to  ensure  that  other 
interclass  connections  are  also  true  for  the  nonbase  class.  Thus,  the  interclass 
assertion  specifies  one  or  more  other  interclass  connections  which  must  also  be  true. 
The  interclass  assertion  would  be  most  beneficial  when  dealing  with  classes  which 
are  user-controllable  classes;  that  is,  the  database  administrator  populates  the 
class.  An  example  of  the  use  of  the  interclass  assertion  to  verify  user-controllable 
classes  is  shown  in  Figure  4-1. 
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CARS_SOLD 

description:  (  All  cars  sold  to  customers.  ) 

interclass  connection:  subclass  of  CARS  where 
specified 

interclass  assertion:  subclass  of  CARS  where 

is  in  PREPARED_CARS  or 
is  in  SCHEDULED_PREPS 

failure  action:  warning 

'car  not  scheduled  for  preparation' 

member  attributes: 

Sold_to 

value  class:  PERSON_NAMES 

Sold_by 

value  class:  PERSONJMAMES 
assertion:  Sold_by  contained  in 

Dealership.Employees 
failure  action: 

error  'Salesman  not  employee  of  dealership' 


class  attributes: 

Number_of_cars_sold 
value  class:  INTEGERS 
derivation:  number  of  unique  members  in 

this  class 
assertion:  Number_of_cars_sold  - 

sizeof  (  SCHEDULED_PPJEPS  )  + 
sizeof  (  PREPARED_CARS  ) 
failure  action: 

call  _determine_cars_not_scheduled 


Figure  4-1.  Use  of  Member  and  Class  Attribute  and  Interclass  Assertions 
Other  known  Interclass  connections  which  can  be  used  to  define  the  same  class  can 
also  be  stated  within  the  interclass  assertion.    An  example  of  the  use  of  the 
Interclass  assertion  Is  shown  in  Figure  4-2. 
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PREPARED_BUICKS 

description:  (  This  class  contains  all  prepared 

Buick's  for  any  dealership.  } 
interclass  connection:  subclass  of  CARS  where 
is  in  BUICKS  and 
is  in  PREPARED_CARS 
interclass  assertion:  subclass  of  PREPARED_CARS  where 
Make  -  'Buick' 

Figure  4-2.  Use  of  the  Interclass  Assertion  as  Multiple  Interclass  Connections 

The  failure  action  for  the  Interclass  assertion  in  Figure  4-2  is  assumed  to  be  the 

error  action.   If  the  Interclass  assertion  were  to  fall,  the  database  administrator 

would  receive  an  error  message  indicating  that  an  invalid  database  state  has  been 

entered. 

4.2  Grouping  Name  Classes 

In  the  real  world,  the  value  of  one  attribute,  A  „  may  determine  the  value  class  of 
another  attribute,  A2.  An  example  of  this  is  the  attributes  "Make"  and  "Model"  of 
class  CARS.  Any  combination  of  Make  and  Model  of  cars  may  not  make  sense.  In 
fact,  the  make  of  a  car  determines  the  possible  models  which  can  be  denned.  That 
is,  the  value  of  name  class  CAR_TYPES  determines  the  value  class  for  the  name 
class  CAR.MODELS.  Thus,  the  name  class  CAR.MODELS  is  actually  a  grouping 
of  value  classes,  where  each  value  class  is  made  up  of  a  list  of  possible  car  models. 

Since  the  value  of  an  attribute  A ,  belonging  to  name  class  C,  determines  the  value 
class,  VC,,  of  an  attribute  A2  belonging  to  name  class  C2,  the  number  of  value 
classes  for  class  C2  is  exactly  the  same  as  the  number  of  members  of  name  class  C,. 
This  is  because  each  value  of  name  class  C ,  determines  one  and  only  one  value  class 
VC,  belonging  to  name  class  C2. 

How  this  extension  would  be  represented  in  the  SDM  schema  is  shown  in  Figure 
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4-3. 

CAR_TYPES 

determines:  CAR_MODELS 
CARJMODELS 


interclass  connection:  grouping  of  STRINGS  as  specified 
by  CAR_TYPES 

Figure  4-3.  Example  of  Grouping  Name  Class  Usage 

In  Figure  4-3,  the  term  "determines"  means  that  a  value  of  the  given  name  class 

(e.g.,  CAR_TYPES)  determines  the  value  class  of  the  other  specified  name  class 

(e.g.,  CAR_MODELS).   Logically,  the  CAR_MODELS  name  class  is  thought  of  as 

being  a  class  which  has  members  which  are  name  classes  (as  in  the  grouping 

subclass  definition).   The  interclass  connection  for  the  CAR_MODELS  name  class 

would  then  specify  that  a  "grouping"  of  name  classes  exist  and  then  specify  the 

predicate,  p,  which  is  used  to  formulate  each  name  class  In  the  group.  Finally,  the 

grouping  name  class  will  indicate  the  name  class  (e.g.,  CAR_TYPES)  which 

determines  which  value  class  of  the  group  will  be  selected.    This  defines  a 

symmetrical  relationship  between  the  name  class  "determining"  the  second  and  the 

name  class  being  "determined  by"  the  first. 

4.3  Constant  Name  Class  Members 

Constant  name  class  members  are  a  method  of  identifying  a  permanent  member  of 
a  given  name  class  which  can  then  be  used  throughout  the  rest  of  the  SDM  schema. 
Constant  name  class  members  are  most  beneficial  when  used  with  the  assertion 
clause  presented  in  section  3.1.  An  example  of  constant  name  class  members  might 
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be  CURRENT_DATE  of  name  class  DATES  and  CURRENT_YEAR  of  name  class 
YEARS.  Typically,  constant  name  class  members  would  be  values  which  would  be 
assigned  by  the  database  administrator  or  some  other  external  source. 

Constant  members  would  be  declared  within  the  name  class  which  it  is  denned  as 
follows: 

C 

definition:  ... 
interclass  connection: ... 
constant  members:  MiM2-—M„ 

where  the  value  of  MxM*....Mn  would  be  automatically  denned  as  the  value  class 
of  C. 

4.4  Sizeof  Class  Operator 

The  sizeof  class  operator  is  supplied  to  add  to  the  capabilities  of  denning  member 
and  class  attribute  assertions.  Simply,  the  sizeof  operator  defines  the  size  of  the 
class  C .  That  is, 

sizeof  (  C  )   =    number  of  members  in  class  C . 
Figure  4-1  demonstrates  the  use  of  the  sizeof  class  operator. 

4.5  Summary 

This  chapter  discusses  some  entensions  to  the  SDM  which  are  included  in  the 
SDML  grammar  as  described  in  Chapter  4.  Appendix  2  and  3  give  the  structure  of 
the  SDML  specification  which  will  be  the  foundation  for  the  development  of  the 
SDML  grammar  in  Chapter  4.  All  of  the  examples  used  in  this  chapter  are 
included  in  the  SDML  specification  shown  in  Appendix  5  (which  is  an  upgrade  of 
the  example  in  Appendix  1). 
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The  following  items  are  Identified  as  warranting  further  study: 

•  Automatic  database  recovery  specifications  in  SDML, 

•  Procedure  specifications  in  SDML, 

•  Further  combining  some  of  the  derivation  predicates  to  support  a  smaller 
subset  of  possible  predicates  while  retaining  current  capabilities. 

•  On  a  larger  scale,  the  SDM  schema  should  be  re-worked  to  provide  a  more 
cohesive  set  of  capabilities  instead  of  seamingly  ad-hoc  capabilities. 

Chapter  4  will  give  a  brief  introduction  to  formal  language  theory  and  begin 
describing  the  design  of  the  SDML  grammar. 
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Chapter  4:  SDML  Grammar  Definitions 

Before  presenting  the  design  of  the  SDML  grammar,  a  short  discussion  on  languages 
and  grammars  is  beneficial.  Afterwards,  the  notation  used  in  the  rest  of  this 
chapter  is  described.  Finally,  the  grammar  for  SDML  will  be  presented. 

5.1   Languages  and  Grammars 

A  language  is  an  ordering  of  symbols  based  on  some  pre-defined  set  of  rules.  The 
symbols  of  a  language  constitute  its  alphabet.  Symbols  of  an  alphabet  are  referred 
to  as  tokens  in  compiler  design.  The  rules  which  govern  how  the  symbols  of  the 
alphabet  may  be  arranged  in  the  language  is  called  the  grammar  for  the  language. 
Thus,  given  an  alphabet,  I,  the  following  holds  for  the  language  L : 

L   C   I*- 
where  Z"   is  defined  as  the  set  of  all  sentences  formed  by  concatenation  of  the 
tokens  from  £  (including  the  null  sentence). 

A  terminal  symbol  is  any  member  of  Z.  Therefore,  a  terminal  symbol  is 
synonymous  with  a  token.  A  nonterminal  symbol  represents  a  substring  of  a 
sentence  in  L .  Nonterminal  symbols  are  used  in  a  grammar  as  a  building  block  for 
sentence  construction.  The  set  of  terminal  symbols,  Z,  and  nonterminal  symbols, 
N ,  are  disjoint;  that  is 

i  n  n  =  *. 

The  production  rules,  i>,  of  a  grammar,  r,  are  a  set  of  rules  which  define  how  the 
terminal  symbols  (or  tokens)  are  built  to  form  the  language,  L .  A  production  rule 
has  the  following  form: 
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a  -  p. 

where  a.0  e  QV  [J  I)' .  In  other  words,  a  production  rule  defines  a  derivation  step 
where  a  string  of  terminal  and  nonterminal  symbols  (a)  derive  another  string  of 
terminal  and  nonterminal  symbols  (0).  A  grammar  r  is  then  defined  to  be  the 
four-tuple 

r  ■  (z.n.p.s,). 

where  S,  is  the  start  symbol  for  the  grammar  r.  The  start  symbol  is  a  special 
nonterminal  symbol  such  that,  through  one  or  more  iterations  of  production  rules 
from  r ,  it  will  derive  all  sentences,  s ,  in  L .  That  is, 

S,    =>*  s.  for  any    s  e  £(I"). 

We  can  therefore  define  the  language  defined  by  grammar  r  to  be  as  follows 


LOT)  m 


JSl'  and  S,    ■>* 


where  S,  =>+  s  means  that  s  can  be  derived  from  the  start  symbol  by 
application  of  one  or  more  production  rules,  P,  from  r. 

Placing  restrictions  on  the  form  of  production  rules  in  a  grammar  r  produces 
several  well  known  classes  of  grammars.  A  grammar  r  is  context-sensitive  if 

a.  a  contains  at  least  one  nonterminal  symbol 

b.  [orj  <    J*' 

The  above  restrictions  imply  that  a  context-sensitive  grammar  is  also  e-free;  that 
is,  no  productions  of  the  form  a  -  e  exist  in  the  grammar,  where  e  is  called  the 
empty  symbol.  A  grammar  r  is  denned  as  a  context-free  grammar  if  the  left  hand 
side  CLHS)  of  every  production  rule  contains  one  and  only  one  nonterminal 
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symbol.  Then  the  form  of  each  production  In  a  context-free  grammar  is 

X  -*  p, 
where  X  «  N  and  0  e  (jv  |J  zT .    Notice  that  the  right  hand  side  (RHS)  of  a 
context-free  grammar  rule  can  be  the  empty  string  e.   This  implies  that  context- 
free  grammars   need  not   be  context-sensitive.    A  left-recursive  grammar  is  a 
context-free  grammar  which  includes  productions  of  the  form 

X    ->    Xv, 
where  X  e  N  and  v  e  (N  \J  E)* . 

The  SDML  grammar  will  be  designed  to  be  context-free,  allowing  empty  symbols 
on  the  RHS  of  rules.  The  SDML  grammar  will,  therefore,  not  be  context-sensitive. 
The  SDML  grammar  will  be  denned  as  a  left-recursive  grammar  to  implement  list 
structures.  Reasons  for  left-recursion  Cvs.  right-recursion)  will  be  discussed  in 
Chapter  5. 

It  is  desirable  a  grammar  to  be  unambiguous;  that  is,  for  each  sentence,  s  eL,  there 
exists  a  unique  parse  tree  for  s  denned  by  r.  When  a  ambiguous  grammar  is 
parsed,  the  parser  must  anticipate  the  intended  meaning  of  the  ambiguous  sentence 
and  "guess"  at  a  derivation  for  the  sentence.  It  is  possible  that,  If  the  parser  guesses 
incorrectly,  the  sentence  cannot  be  fully  reduced  given  the  derivation  chosen  by  the 
parser.  Since  it  has  been  proven  that  there  exists  no  algorithm  which  can  take  an 
arbitrary  context-free  grammar  and  prove  that  it  is  ambiguous  or  not  [10][ll],  a 
general  statement  about  the  ambiguity  of  the  SDML  grammar  presented  cannot  be 
made  here.  Therefore,  the  question  of  SDML  grammar  ambiguity  will  be  left  to 
Chapter  5  (where  the  SDML  parser  will  be  discussed).  Note,  however,  that  some 
automatic  parser  generators  (including  the  one  chosen  for  the  SDML  grammar)  do 
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supply  disambiguating  rules  for  resolving  ambiguities  in  the  grammar. 

The  SDML  grammar  will  be  developed  as  an  LRU)  grammar.  The  primary  reason 
for  choosing  an  LRU)  grammar  for  SDML  is  to  allow  the  use  of  already  existing 
parser  generators  for  parsing  an  SDML  specification.  An  LRU)  grammar  is  one 
which  can  be  parsed  Left-to-right  producing  a  Rightmost  derivation  in  reverse, 
with  one  token  look  ahead.  Barrett  and  Couch  [10]  give  the  following  definition 
for  an  LRU)  grammar.  Consider  a  grammar  r  with  start  symbol  S,  and  a 
rightmost  derivation  of  a  terminal  string  w  as  follows: 

S,    =>w1=>w2=>     ■■■    =>w. 
Now  consider  a  typical  step  in  the  derivation: 

aAt  =  >  a/3t . 
where  A  -  0  is  the  production  used  to  reduce  aAt  to  apt,  and  aft  is  one  of  the 
w,.  Then  r  is  LRU)  if,  for  every  such  derivation  step,  the  production  A  ->  0  can 
be  inferred  by  scanning  or/3  and  the  first  token  of  v.  In  this  definition,  t  e  z' , 
AtN,aRda,pe(z\J  NT .  Developing  an  LR(l)  grammar  for  SDML  will  allow 
for  the  design  of  a  shift-reduce  parser  for  SDML  with  a  one  token  look  ahead. 

Notice  that  an  LRU)  grammar  provides  an  extremely  powerful  language 
specification.  That  is,  the  amount  of  information  used  to  infer  a  reduction  can  be 
immense.  That  is,  the  entire  stack  of  shifted  symbols  (i.e.,  o0)  as  well  as  the  first 
token  of  v,  is  used  to  infer  the  reduction  by  the  production  A  -  0.  How  the 
parser  actually  implements  this  is  left  to  Chapter  5. 
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5.2  Notation 

In  the  SDML  grammar  specification  described  in  the  next  section,  the  following 
notation  is  used: 

1.  Nonterminal  symbols  are  lower-case  characters  enclosed  within  the  <  and 
>  symbols  (e.g.,  <class-attributes>). 

2.  Terminal  symbols  are  denoted  as  upper-case  strings, 

3.  If  two  productions  (e.g.,  X  -  Y  and  X  ->  Z )  have  the  same  LHS,  they  are 
shown  as 

X   ::-  Y  \ 
Z. 

where  the  T  symbol  represents  an  alternative.   A  production  of  the  above 

form  represents  the  Backus-Naur  Form  (BNF)  for  the  grammar,  r.    The 

SDML  grammar  will  be  presented  in  the  BNF  format. 

4.  When  referring  to  a  mapping,  the  terminology  AMX  will  be  used  (read 
Attribute  Mapping  sub  1).  When  referring  to  a  mapping  list,  AMt  will  be 
used. 

5.  Defining  the  attribute  mapping  AMx  as  a  mapping  of  attributes  Nt  (i.e., 
tf  iJV2.  •  •  •  JVm),  then  attribute  Nt  in  the  mapping  sequence  within  AM  i  is 
referenced  as  (AM^"'. 

6.  The  value  class  for  an  attribute  or  mapping  (say  AM, )  will  be  denoted  by 
VCAMl  (read  "the  value  class  of  AM"). 
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7.    The  underlying  base  class  for  class  C,  is  denoted  as  UCj  (read  "the  underlying 
base  class  of  C,"). 

Class  names,  attribute  names,  procedure  names,  constant  member  names,  and 
labels  are  considered  as  terminal  symbols  in  the  discussion  since  they  are  passed 
from  the  lexical  analyzer  as  such. 

5.3  SDML  Grammar  Specification 

This  section  will  discuss  the  development  of  the  grammar  for  SDML.  With  each 
production  sequence,  the  semantic  checks  which  will  be  performed  by  the  SDML 
parser  are  listed.  All  production  rules  are  listed  in  Appendix  4  as  they  were  given 
to  the  Yacc  program.  The  order  of  the  discussion  follows  the  order  of  the 
productions  given  in  Appendix  4. 

The  following  checks  will  be  made  in  reference  to  class  and  attribute  name 
definitions: 

a.  class  name  definitions  must  be  unique  for  all  classes  denned  in  the  SDML 
specification. 

b.  attribute  name  definitions  must  be  unique  for  the  underlying  base  class,  U, 
and  all  eventual  subclasses  of  U . 

c.  constant  member  name  definitions  must  be  unique  with  respect  to  all 
constant  member  names  defined  in  the  SDML  specification. 

As  discussed  in  Chapter  2,  the  SDM  schema  is  made  up  of  one  or  more  class 
definitions.  Thus,  the  SDML  grammar  start  symbol  will  be  <sdm-schema>  and 
will,  therefore,  be  denned  as  a  class  definition  list  as  follows: 
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<sdm-schema>  :>  <class-definition-list> 
A  class  definition  list  can  be  either  a  single  class  or  multiple  class  definition  lists. 
In  either  case,  a  first  (and  last)  class  definition  must  be  present.  The  <class- 
definition-list>  nonterminal  could  then  consist  of  a  single  class  definition  or  a  last 
class  definition  preceded  by  other  class  definitions  (i.e.,  another  class  definition 
list): 

<  class-definition-list  >    ::-   <  class-definition  >    I 

<  class-definition-list  >    <  class-definition> 

Base  and  nonbase  class  definitions  can  be  mixed  withing  the  SDML  specification. 

As  discussed  In  Chapter  2,  a  class  in  the  SDM  schema  is  either  defined  as  as  base 
class  or  a  nonbase  class.  The  distinction  between  base  and  nonbase  classes  is  not 
declared  explicitly  In  the  SDM  schema  with  the  class  name,  but  is  implicit  in  how 
the  class  Is  defined.  A  distinction  can  be  made  between  base  classes  and  nonbase 
classes  by  the  presense  of  an  interclass  connection.  All  nonbase  classes  have 
interclass  connections  and  no  base  classes  have  interclass  connections.  Therefore, 
no  conflict  should  arise  in  the  grammar  If  the  class  definition  produces  either  a  base 
class  definition  or  a  nonbase  class  definition  as  follows: 

<  class-definition >    ::-   <base-class-definition>    I 

<  nonbase-class-def  > 

Let  us  first  concentrate  on  the  base  class  definition.  Every  class,  whether  base  or 
nonbase,  is  identified  with  a  unique  class  name  possible  followed  by  multiple 
synonymous  names.  The  class  name  list  is  then  followed  by  the  body  of  the  base 
class  as  follows: 

<  base-class-definition >    ::-    <class-name-list>  <base_class_body> 

The  class  name  list  is  headed  by  the  primary  name  for  the  class  optionally 


■31- 


followed  by  the  list  of  synonymous  names  separated  by  comma's  or  and's: 

<  class-name-list  >    ::-  CLASS_NAME  I 

<  class-name-list  >  <comma-and-sep>  CLASS_NAME 

<comma-and-sep>    ::-  7  I  AND 

Within  the  list  of  semantic  checks  for  declarations  within  the  body  of  this  class, 

the  primary  name  of  the  class  presently  being  denned  will  be  C . 

Now  for  the  definition  of  the  body  of  a  base  class.  A  base  class  is  made  up  of  an 
optional  description,  an  optional  base  class  features  declaration,  one  or  more 
member  attributes,  zero  or  more  class  attributes,  and  a  list  of  identifiers.  Thus,  the 
body  of  a  base  class  is  as  follows: 

<base_class_body>  :>  <desc-clause>  <bc-feat-decl> 
<member-attr-decl>  <class-attr-decl> 
<ident-decl> 

The  description  clause  allows  the  designer  to  provide  an  Engligh  language  sentence 

for  documentation  purposes.  The  description  clause  has  the  following  format: 

<desc-clause>    :>  e  I 

DESCRIPTION  :  DESCRIPTION_TEXT 

Base  class  features  allow  the  designer  to  specify  whether  or  not  duplicates  are 

allowed  within  this  class.    If  not  specified,  the  default  is  that  duplicates  are 

allowed.  The  base  class  features  declaration  is  then 

<bc-feat-decl>    ::-  £   I 

DUPLICATES  NOT  ALLOWED  I 
DUPLICATES  ALLOWED 

Every  base  class  must  have  one  or  more  member  attributes  defined  for  the  class. 

Thus  the  productions 
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<member-attr-decl>    ::-  MEMBER  ATTRIBUTES  :  <member-attr-list> 

<member-attr-list>    ::-    <member-attribute>    I 

<member-attr-list>  <  member-attribute > 

define  the  format  of   member   attribute  definitions   within   a   class.    Member 

attributes  are  identified  by  an  attribute  name  optionally  followed  by  multiple 

synonymous  attribute  names.  Member  attribute  names  must  be  unique  within  all 

attributes  (member  and  class)  of  this  class  and  all  eventual  subclasses  of  this  class. 

The  body  of  a  member  attribute  contains  the  description  clause  (exactly  as  in  the 

class  definition),  the  value  class  declaration  for  the  attribute,  an  optional  inverse 

relationship,  an  optional  match  or  derivation,  a  member  order  defining  the  order  of 

the  attribute,  and  member  attribute  options.    Added  to  the  member  attribute 

definition  is  the  member  attribute  assertion.    Thus,  the  production  defining  a 

member  attribute  definition  is  as  follows: 

<member-attribute>    ::-   <attr-name-list>  <desc-clause> 

<  value-class-decl  >  <  in verse-decl  > 

<  match-or-derivation  >  <  member-order  > 
<member-attx-opts>  <attr-assertion-decl> 

<attr-name-list>    :>  ATTRIBUTE_NAME  I 

<attr-name-list>  comma-and-sep  ATTRIBUTE_NAME 

The  primary  name  for  the  attribute  currently  being  built  will  be  A  Cwithin  class 
C). 

The  value  class  declaration  defines  the  value  class  from  which  the  attribute  will 
derive  its  value.  The  value  class  declaration  is  as  follows: 

<value-class-decl>    ::-  VALUE  CLASS  :  CLASSJVAME 
The  value  class  definition  for  A  will  be  denoted  VCA  . 


The   inverse   declaration   allows   the   designer   to   define 


an   inverse   attribute 
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interrelationship  between  this  attribute  and  another.  An  inverse  relationship 
logically  defines  an  assertion  between  this  attribute  and  the  inverse  attribute. 
Therefore,  any  additional  assertions  will  be  redundant.  Recall  from  Chapter  2  that 
the  inverse  attribute  must  have  a  value  class  of  the  class  presently  being  defined 
and  this  attribute  must  have  a  value  class  of  the  inverse  attributes  underlying 
class.  These  checks,  however,  will  not  be  made  here  since  the  inverse  attribute 
may  not  have  been  defined  yet.  The  inverse  checks  will  be  made  at  the  end  of  the 
first  pass  after  all  classes  and  attributes  have  been  discovered  and  appropriate 
symbol  tables  have  been  built.  The  inverse  declaration  is  defined  as  follows: 

<inverse-decl>    ::-  INVERSE  :  ATTRIBUTE_NAME 
The  semantic  checks  which  will  be  performed  on  the  <inverse-decl>  production 
are  as  follows: 
Production: 

<inverse-decl>    — >    inverse  :Ai 
Checks: 

i.    A  i  is  defined  as  a  member  attribute  within  VCA 
il.    A  i  has  a  value  class  of  C 
ill.    A  x  has  "Inverse  :  A "  definition 
As  well  as  an  inverse  declaration,  the  member  attribute  can  contain  either  a  match 
or  derivation  (but  not  both).  Therefore,  the  production 

<match-or-derivation>    ::-   <match-decl>    I 
<  deri  vation-decl  > 

will  provide  the  excluslve-or  capability.    Any  member  attribute  definition  rules 

will  be  applied  to  the  class  definition  after  pass  1   when  all  required  data  is 

available  to  perform  the  checks. 
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The  match  attribute  interrelationship  is  denned  by  the  following  production: 

<match-decl>    ::-  MATCH  :  ATTRIBUTE_NAME  OF  CLASS_NAME 
ON  ATTRIBUTE_NAME 

All  checks  on  attribute  value  classes  and  underlying  classes  noted  in  Chapter  2 
will  be  done  after  pass  1  of  the  parser  when  all  required  data  is  available.   These 
semantic  checks  are  as  follows: 
Production: 

<  match-decl>   — >    match:  A  t  of  C  i  on  A  2 
Checks: 

i.    A  i  and  A  2  must  be  defined  as  member  attributes  within  C  i 
ii.    A 1  has  a  value  class  of  VCA 
ill.    A2  has  a  value  class  of  C . 
iv.    if  A  has  an  inverse  declaration  (call  it  A3),  then 

a.  A  3  has  no  derivation  declaration. 

b.  if  A  3  has  a  match  declaration  then  it  must  be: 

match:  A  2  of  C  i  on  A  t. 
The  derivation  attribute  interrelationship  is  denned  by  the  following  production: 

<derivation-decl>    :>  DERIVATION  :  <member-attr-deriv> 
where  the  <  member-attr-deriv>  defines  all  legal  attribute  derivations  for  member 
attributes.  The  following  semantic  checks  will  be  make  for  the  given  production: 
Production: 

<dcrivation-decl> *    derivation:  <mcmber-attr-deriv> 

Checks: 

i.    if  A  has  an  inverse  declaration  (call  it  A3)  then: 
a.    A  3  has  no  derivation  declaration. 
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b.    A3  has  no  match  declaration. 
Member  attribute  derivations  will  be  discussed  later  in  this  chapter. 

The  member  order  for  a  member  (or  a  class)  attribute  defines  the  member  Cor 
class)  attribute  to  be  either  single  valued  or  multivalued.  Multivalued  attributes 
can  also  have  a  restriction  on  the  number  size  of  the  attribute  (i.e.,  array  size).  If 
member  order  is  not  specified,  then  single  valued  is  assumed.  The  production  for 
member  order  is  as  follows: 

<  member-order  >    ::=-  e   I 

SINGLE  VALUED  I 

MULTIVALUED  I 

MULTIVALUED  WITH  SIZE  BETWEEN  I 

INTEGER_C  AND  INTEGER_C 

Note  that  the  bounds  on  the  array  size  must  be  specified  as  being  between  two 

integer  constants. 

Member  options  allow  the  designer  to  specify  one  of  four  possible  attribute 
options.  The  phrase  "may  not  be  null"  may  be  specified  which  indicates  that  the 
attribute  cannot  contain  the  special  value  null.  The  attribute  can  be  declared  as 
"not  changeable"  which  implies  that  once  a  non-null  value  is  given  to  the  attribute, 
it  cannot  be  changed.  The  "exhausts  value  class"  phrase  within  the  definition  of 
attribute  A  for  class  C  indicates  that  for  every  value  V  in  the  value  class  for  the 
attribute  A ,  there  must  exist  at  least  one  member  AT,  of  the  underlying  class  C 
such  that  the  attribute  A  value  for  that  member  M,  is  that  value  V.  The  "no 
overlap  in  values"  phrase  indicates  that  if  some  member  M,  of  class  C  has  contains 
a  value  V  for  attribute  A ,  then  there  cannot  exist  another  member  Mt  such  that 
the  attribute  A  value  of  member  M,  is  contains  V.  The  "no  overlap  in  values" 
option   is  only  valid   for  multivalued   member  attributes  since  single  valued 
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attributes  are  nonoverlapping  by  definition.  Any  or  none  of  the  above  mentioned 
options  can  be  specified  for  a  member  attribute.  The  BNF  sequence  for  definition  of 
member  attribute  options  is  thus: 

<member-attr-opts>    ::-   <member-options>    I  6 

<  member-options >    :>    <  member-opt-item > 

< member-options >  <member-opt-item> 

<member-opt-item>    :>  MAY  NOT  BE  NULL  I 
NOT  CHANGEABLE  I 
EXHAUSTS  VALUE  CLASS  I 
NO  OVERLAP  IN  VALUES 

The  reason  for  designing  the  grammar  to  allow  a  list  of  the  available  options  Is  to 

allow  the  options  to  be  entered  in  any  order.  This  does,  however,  allow  a  single 

option  to  be  entered  more  than  once  within  the  same  member  attribute  definition. 

The  parser  can  detect  this  at  the  time  of  the  parsing  and  simply  reduce  the 

redundant  definitions  to  a  single  definition.    The  following  semantic  checks  are 

made  for  the  indicated  member  options: 

Production; 

<member-opt-item> >    exhausts  value  class 

<member-opt-item> ►    no  overlap  in  values 

Checks: 

I.  A  is  denned  as  a  multivalued  attribute. 
The  member  attribute  assertion  extension  allows  some  statement  of  fact  to  be 
made  about  this  member  attribute,  other  member  attributes  within  this  class,  class 
attributes  within  this  class,  or  constants.  Mappings  can  be  used  when  referencing 
member  attributes  within  this  class  to  reference  lower  level  data  values.  A 
member  attribute  assertion  is  made  up  of  one  or  more  assertion  statements 
followed  by  a  failure  action  if  any  one  of  the  assertions  were  to  fail.  Therefore, 
the  productions  involving  declaration  of  a  member  attribute  assertion  are  as 
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follows: 

<attr-assertion-decl>    ::-  e   I 

<  attr-assertion-1  ist  >   <  fail-action-clause  > 

<attr-assertion-list>    ::-   <auribute-assenion>   I 

< attr-assertion-list>  < attribute-assertion > 

<  attribute-assertion >    ::-  ASSERTION  :  <assertion> 

One  of  three  possible  assertions  can  be  used  in  the  member  attribute  assertion: 

1.  A  call  to  a  user-defined  procedure  which  will  provide  the  necessary  data 
checks  to  verify  the  current  database  state. 

2.  A  comparison  of  two  arithmetic  expressions  involving  member  attributes 
and  class  attributes  within  this  class  and  constants.  With  this  type  of 
member  attribute  assertion,  each  of  the  arithmetic  expressions  must  evaluate 
to  a  number  value  (INTEGER_C  or  REAL_C).  The  comparison  can  be  made 
with  any  one  of  the  relational  operators. 

3.  A  statement  indicating  a  set  relationship  between  this  member  attribute  and 
one  of:  (1)  some  other  attribute  or  mapping  within  this  class,  (2)  a  class 
attribute  within  this  class,  or  (3)  another  class.  The  two  set  operators 
which  can  ge  used  (defined  later)  are  the  "is  contained  in"  and  the  "contains" 
operators.  When  the  "is  contained  in"  operator  Is  used,  the  RHS  of  the 
comparison  must  be  a  multivalued  attribute  or  a  class.  When  the  "contains" 
operator  is  used,  the  LHS  of  the  comparison  (representing  the  attribute  being 
denned)  must  be  a  multivalued  attribute. 

The  productions  which  define  the  member  attribute  assertion  is  then  as  follows: 


■58- 


<assertion>    ::-  CALL  PROCEDURE_NAME  I 

<mapping-expression>  <relop>  < mapping-expression >    I 
<  setop-predicate  > 

With  a  member  attribute  assertion  list,  an  optional  failure  action  can  be  supplied 

which  indicates  the  action  to  take  when  the  member  attribute  assertion  fails.  One 

of  three  possible  failure  actions  are  possible: 

1.  Call  a  user-defined  procedure  which  will  handle  the  error  recovery  from  the 
invalid  database  state.  Note  that  the  user-defined  procedure  is  then 
responsible  for  re-checking  the  new  database  state  if  an  attempt  was  made 
to  correct  the  error. 

2.  Flag  the  database  state  as  an  error  state  and  report  the  error  to  the  database 
administrator.  An  optional  action  message  can  be  supplied  to  supply 
additional  information  to  the  database  administrator.  The  action  message  is 
denned  later  in  the  SDML  grammar. 

3.  Warn  the  database  administrator  of  the  condition  with  a  message.  This 
assertion  may  not  actually  represent  an  invalid  database  state,  but  might  be 
used  to  notify  the  database  administrator  when  the  member  attribute  takes 
on  some  specified  value(s). 

The  productions  involved  in  specifying  the  failure  action  for  a  member  attribute 
assertion  are  then: 


<  fail-action-clause >    ::-  6   I 

FAILURE  ACTION  :  <  failure-action  > 

<  failure-action  >   ::-  CALL  PROCEDURE_NAME  I 

ERROR  <  action-message  >    I 
WARNING  STRING_C 
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The  optional  class  attributes  declaration  section  of  a  class  definition  can  contain 
one  or  more  class  attribute  definitions.  Thus  the  productions 

<class-attr-decl>    ::-  e  I 

CLASS  ATTRIBUTES  :  <class-attr-list> 

<class-attr-list>    ::-   < class-attributes > 

<class-attr-list>  <class-attributes> 

begin  the  definition  of  the  class  attribute  declaration  section. 

Any  given  class  attribute  is  uniquely  identified  with  the  attribute  name.  Class 
attributes  can  also  be  given  multiple  synonymous  names.  As  with  member 
attribute  names,  the  class  names  must  be  unique  within  the  underlying  base  class 
and  all  eventual  subclasses  of  the  base  class.  Class  attributes  contain  an  optional 
description  clause,  a  value  class  declaration,  an  optional  class  derivation 
declaration,  member  order  definition,  class  attribute  options,  and  an  optional  class 
attribute  assertion.  The  definition  of  the  class  attribute  is  then 

< class-attribute >    ::-   <attr-name-list>  <desc-clause> 
<value-class-decl>   <class-deriv-decl> 
<member-order>  <class-attr-opts> 
<  attr-assertion-decl  > 

where  the  <attr-name-list>,   <desc-clause>,   <  value-class-decl> ,   <member- 

order>,  and  <  attr-assertion-decl  >  are  defined  in  exactly  the  same  way  as  for  the 

member  attribute  definition.   The  class  attribute  options,  however,  are  either  "may 

not  be  null"  or  "not  changeable".  The  "exhausts  value  class"  and  the  "no  overlap  in 

values"  options  do  not  make  sense  here  since  there  is  only  a  single  instance  of  the 

class   attribute   independent   of   the   number   of   members   of   the   class.     The 

productions  for  the  class  attribute  options  are 
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<class-attr-opts>    ::-   <  class-options  >    I  e 

<  class-options >    ::-   <class-opt-item>    I 

< class-options >  <class-opt-item> 

<  class-opt-item  >    :>  MAY  NOT  BE  NULL  I 

NOT  CHANGEABLE 

The  optional  class  derivation  declaration  is  specified  as  follows: 

<class-deriv-decl>    ::-  e  I 

DERIVATION:  < class-attr-deriv> 

where  <class-attr-deriv>  defines  the  valid  derivation  primitives  which  can  be 
used  for  class  attributes. 

Let  us  first  begin  the  discussion  of  derivation  primitives  with  the  member  attribute 
derivation  since  It  was  Introduced  first  In  the  SDML  grammar.  A  member 
attribute  derivation  can  be  either  an  interattribute  derivation  or  a  member-specific 
derivation.  Interattribute  derivations  are  those  which  can  appear  in  either  the 
member  attribute  derivation  or  the  class  attribute  derivation.  Thus,  the 
productions  for  the  member  attribute  derivation  are 

<member-attr-deriv>    ::-    <interattr-deriv>    I 
<member-spec-deriv> 

An  Interattribute  derivation  used  within  a  member  attribute  derivation  requires 

the  following  semantic  check(s)  be  made: 

Production: 

<member-attr-deriv> >    <interattr-deriv> 

Checks: 

1.    (AMi )  >  must  be  defined  as  a  member  attribute  within  class  C . 
Member-specific  derivations  are  derived  using  one  of  four  predicates:  (1)  ordering 
predicate,  (2)  existence  predicate,  (3)  recursive  trace  predicate,  or  (4)  contents 
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predicate.  The  member-specific  derivation  is  then  defined  as  follows: 

<member-spec-deriv>    :>    <ordering-predicate>    I 

<  existence-predicate  >    I 

<  recursi  ve-trace-pred  > 

The  ordering  predicate  defines  the  member  attribute  to  be  the  sequential  position  of 
the  member  when  ordered  by  some  specified  attribute(s).  The  ordering  can  be 
either  increasing  or  decreasing  (default  is  increasing).  The  ordering  predicate  can 
also  define  the  attribute  to  be  the  sequential  position  of  the  member  when  ordered 
by  some  specified  attribute(s)  grouped  on  a  common  value  of  some  other  specified 
attributed)  by  using  the  within  clause.  Since  the  attribute  has  a  value 
representing  the  sequential  position  of  the  member  within  some  list,  the  ordering- 
predicate  requires  the  value  class  of  the  attribute  to  be  an  integer  constant  (value 
class  INTEGERS).  The  productions  which  define  an  ordering  predicate  are 

<ordering-predicate>    ::-  ORDER  BY  <direction> 
<mapping-list>   <within-clause> 

<direction>    ::-  INCREASING  I  DECREASING  I  £ 

<within-clause>    ::-  WITHIN  < mapping-list  >   I  6 

<mapping-list>    ::-   <mapping>    I 

<  mapping-list  >  <comma-and-sep>  <  mapping  > 

The  productions  from  above  with  their  checks  are  listed  below: 

Production: 

<ordering-predicate>   — >    order  by  AMt  <within-clause> 
Checks: 

i.    VCA  m  INTEGERS 


II.    (AW,- )  '  must  be  defined  in  C  for  all  i  Ink. 


Production: 
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<within-clause> >    within  AMj 

Checks: 

1.    {AM j  )"'  must  be  denned  in  C  for  all  / . 
The  existence  predicate  defines  an  attribute  to  be  either  "true"  or  "false"  based  on 
whether  the  member  is  a  member  of  some  specified  class.  The  production 

<existence-predicate>    ::-  IF  IN  CLASS_NAME 
defines  an  existence  predicate.    Since  the  existence  predicate  defines  a  yes/no 
alternative,  the  value  class  of  the  denning  attribute  must  be  the  built-in  class 
YES/NO.  The  checks  for  the  existence  predicate  are  as  follows: 
Production: 

<  existence-predicate  > >    if  in  Ct 

Checks: 

i.    Ct  =  YES/NO 

a.  uc  =  uCi 

The  recursive  trace  predicate  defines  the  value  of  the  attribute  A  to  be  all  members 
which  are  found  by  recursively  tracing  the  values  of  some  specified  attribute  A ,  of 
the  same  class  C.  In  order  for  the  recursive  trace  predicate  to  make  sense,  both 
attributes  A  and  A  i  must  have  a  value  class  of  the  underlying  class  C.  A  limit 
can  also  be  placed  on  the  level  of  the  recursive  trace.  The  productions  which  define 
the  recursive  trace  predicate  are 

<recursive-trace-pred>    ::-    <level-clause>  LEVELS  OF  VALUES 
OF  ATTRIBUTE_NAME 

<  level-clause >    ::-  UP  TO  INTEGER_C  I  ALL 
The  semantic  checks  for  the  recursive  trace  predicate  are  as  follows 
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Production: 

<recursive-trace-pred>   — >    <  level-clause >  levels  of  values  of  A ! 
Checks: 

1.    VCA  =  C, 

II.  vcAi  =  c, 

III.  A !  is  defined  as  a  member  attribute  attribute  within  class  C . 
Next,   the   class   attribute   derivation   will   be   discussed.    The  class   attribute 
derivation  can  be  either  an  interattribute  derivation  or  a  class-specific  derivation. 
The  production  for  the  class  attribute  derivation  is  then 

<class-attr-deriv>    ::-   <  interattr-deriv>    I 
<  class-spec-deri  v  > 

An  Interattribute  derivation  used  within  the  class  attribute  derivation  requires  the 

following  semantic  check: 

Production: 

<class-attr-deriv> >    <interattr-deriv> 

Checks: 

1.    {AM t )  '  must  be  defined  as  a  class  attribute  within  class  C . 
First,  the  class  specific  derivation  will  be  discussed  followed  by  the  interattribute 
derivation  (which  can  be  used  by  either  the  class  attribute  derivation  or  the 
member  attribute  derivation).  Two  types  of  class-specific  derivation  predicates  are 
allowable:  the  class  size  predicate  and  the  class  member  predicate: 

<class-spec-deriv>    ::-    <class-size-pred>    I 
<  class-mem  ber-pred  > 

The  class  size  predicate  defines  the  attribute  to  be  the  number  of  members  in  the 

underlying  class.  The  class  member  predicate  defines  the  attribute  to  be  the  sum, 

average,  minimum,  or  maximum  of  some  member  attribute  taken  over  all  members 
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of  the  underlying  class.  The  following  productions  define  the  class-specific 
derivation  predicates: 

<class-size-pred>    ::-  NUMBER  OF  <uniqueness>  MEMBERS 
IN  THIS  CLASS 

<  uniqueness  >    ::-  UNIQUE  I  e 

<class-member-pred>    ::-    <  set-function  >  OF  ATTRIBUTE_NAME 
OVER  MEMBERS  OF  THIS  CLASS 

<  set-function  >    :>  MINIMUM  I  MAXIMUM  I  AVERAGE  I  SUM 

The  following  semantic  checks  must  be  made  within  the  following  productions 
from  above: 
Production: 

<class-size-pred> >    number  of  <uniqueness>  members  in  this  class 

Checks: 

i.    VCA  m  INTEGERS. 
Production: 

<class-member-pred> >    <set-function>  of  A !  over  members  of  this  class 

Checks: 

i.    A  i  must  be  denned  as  member  attribute  within  class  C . 

11.    Given  Ci  is  the  value  class  of  A ,  Uc    =  NUMBERS,  REALS,  or 
INTEGERS. 

ill.    Given  C2  =   value  class  of  A„  UCl  m   NUMBERS,  REALS,  or 
INTEGERS. 

The  interattrlbute  derivation  can  be  specified  using  one  of  four  predicates:  (1)  set- 
derived  predicate,  (2)  equality  predicate,  (3)  set-order  predicate,  or  (4)  subvalue 
predicate: 
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<  interattr-deriv>    ::-   <  derived-predicate  >    I 

<  set-derived-pred  >    I 

<  equality-predicate  >    I 

<  set-order-predicate  >    I 

<  subvalue-predicate  > 

The  derived  predicate  specifies  that  the  attribute  A  is  directly  derived  from  another 
attribute  mapping.  The  production 

<  derived-predicate >    ::-  SAME  AS  <  mapping  > 

defines  a  derived  predicate.   The  semantic  checks  required  for  the  derived  predicate 
are  as  follows: 
Production: 

<  derived-predicate  >    — >    same  as  A  Mi 
Checks: 

i.    (AM  {f*  is  denned  in  C 

ii-    VCAMl  (i.e.,  value  class  of  (AMif")  =  VCA 
The  set-derived  predicate  defines  the  members  of  the  attribute  to  be  those  members 
which  are  either  in  the  union  of  two  attribute  mappings,  in  the  intersection  of  two 
attribute  mappings,  or  in  the  difference  of  two  attribute  mappings.  The  production 

<set-derived-pred>    ::-  WHERE  IS  IN  <  mapping >  AND  IS  IN  <  mapping >    I 
WHERE  IS  IN  <mapping>  OR  IS  IN  <mapping>    I 
WHERE  IS  IN  <  mapping  >  AND  IS  NOT  IN  <  mapping  > 

defines  the  set-derived  predicates  for  the  interattribute  derivations.  The  following 

semantic  checks  will  be  performed  for  the  set-derived  predicate: 

Production: 

< set-derived-pred > >    where  is  in  AMt  and  is  in  AM2 

<  set-derived-pred  > >    where  is  in  AM !  or  is  in  AM2 

<  set-derived-pred  > >    where  is  in  AMt  and  is  not  in  AM  2 

Checks: 
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i.    both  {AM  0"1  and  (m/1  must  be  denned  appropriately  within 
class  C 

il.    Given  Cx  is  the  value  class  of  AM  ^  and  C2  is  the  value  class  of 
AM2,  then  UCl  =  VCA  and  UCj  =  VCA  -1 

ill.    AM  i  and  AM 2  must  be  multivalued  attribute  mappings 
The  equality   predicate   defines  the  attribute  to   be  directly   derived  from  an 
arithmetic  expression  involving  the  following: 

•  set  functions  on  multivalued  member  attributes, 

•  other  member  attributes, 

•  number  constants, 

•  constant  member  names, 

•  size  of  multivalued  member  attributes,  or 

•  size  of  classes. 

Thus  the  series  of  productions  which  define  an  equality  predicate  are  as  follows: 
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<  equality-predicate >    ::-  EQ  <  mapping-expression  > 

<  mapping-expression  >    :>    <  mapping-term  >    I 

< mapping-expression >   <addition-operator>  <mapping-term> 

<  mapping-term >    :>    <  mapping-factor  >    I 

< mapping-term >  <multiply-operator>  <  mapping-factor > 

<  mapping-factor >    ::-    <  mapping-primary  >    I 

<  mapping-factor  >  <  exponent-operator  >  <  mapping-primary  > 

<  mapping-primary >    ::-  (  <mapping-expression>  )  I 

<  set-function  >  (  <  mapping  >  )   I 

<  mapping  >    I 

<  number  >    I 

CONST_MEMBER_NAME  I 
SIZEOF(  <  mapping  >  )   I 
SIZEOF  (  CLASS_NAME  ) 

<  addition-operator >    ::-  +  I  - 
<multiply-operator>    S-  *\l 

<  exponent-operator >    ::=   ! 

The  following  semantic  checks  will  be  made  for  the  productions  withing  the 
equality  predicate: 
Production: 

<  equality-predicate  > >    -  <  mapping-expression  > 

Checks: 

1.    for  all  mappings  AMt  in  <  mapping-expression> ,  (Aitf;)"1  must 
be  appropriately  defined  within  C 

11.    Uvc^  =  NUMBERS,  REALS,  or  INTEGERS 

Production: 

<  mapping-primary  > <  set-function  >(  AAf!  ) 

Checks: 

i.    Given  C,  =  VC^,,  UCi  m  NUMBERS,  REALS,  or  INTEGERS 

il.    AM !  must  be  a  multivalued  attribute  or  mapping 
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Production: 


<  mapping-primary  > >    AM, 

<mapping-primary> >    sizeof  (  AM ,  ) 

Checks: 

i.    AM  ,  must  be  a  multivalued  attribute  or  mapping 
Production: 

<  mapping-primary > >    CONST_MEMBER_NAME 

Checks: 

i.    CONST_MEMBER_NAME  must  be  denned  within  a  name  class 
C,  such  that  Bb,  =  NUMBERS,  REALS,  or  INTEGERS 

The  set-order  predicate  defines  the  value  of  the  attribute  to  be  the  number  of 

members  in  some  specified  eventual  attribute  of  a  mapping.  The  production 

<  set-order-predicate >    ::-  NUMBER  OF  <  uniqueness  > 
MEMBERS  IN  <mapping> 

defines  the  set-order  predicate.  The  semantic  checks  which  will  be  performed  for 

the  set-order  predicate  are  as  follows: 

Production: 

<  set-order-predicate  > >    number  of  <  uniqueness  >  members  in  A M  , 

Checks: 

I.    (AM,)  *  is  defined  appropriately  within  class  C 

it    AM  i  is  a  multivalued  attribute  or  mapping 

ul.  VCA  =  INTEGERS 
The  subvalue  predicate  defines  the  attribute  A  to  be  a  subvalue  of  another  mapping 
Aj  which  satisfies  some  condition.  The  conditions  can  be  either  CD  values  of  A1 
which  are  members  of  some  class  d,  or  (2)  values  of  A,  which  satisfy  some 
attribute  predicate.  The  attribute  predicate  will  be  described  later  in  this  chapter. 
All  mappings,  C„  and  A,  must  be  the  value  class  of  A  (i.e.,  must  be  VCAX  The 
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productions  which  form  the  subvalue  predicate  are: 

<subvalue-predicate>    ::-  SUBVALUE  OF  <  mapping  >  WHERE 
<  sub  value-selection  > 

<subvalue-selection>    :>  IS  IN  CLASS_NAME  I 
<  attribute-predicate  > 

The  semantic  checks  which  will  be  made  for  the  above  productions  are  as  follows: 
Production: 

<subvalue-predicate>   — «    subvalue  of  AMt  where  <  sub  value-selection  > 
Checks: 

1.    (AMJ  '  Is  denned  appropriately  within  class  C 
11.    AM ,  is  a  multivalued  attribute  or  mapping 
ill.    VCU^  =  VCA 
Production: 

<  subvalue-selection  > >    is  in  C  i 

Checks: 

1.    given  that  C2  s  VC^,  then  Uc2  =  f/C] 
Production: 

<  subvalue-selection  >   — >    <  attribute-predicate  > 
Checks: 

i.     <attribute-predicate>  must  satisfy  definition  for  class  VCA 
A  mapping  is  a  sequential  reference  of  attributes  based  on  the  value  class  of  each 
attribute.  Mappings  are  denned  in  the  SDML  grammar  as  follows: 

<  mapping  >    ::-  ATTRIBUTE_NAME  I 

<  mapping  >  .  ATTRIBUTE_NAME 

Consider  a  mapping  NtJft.  •  •  •  jvm  where  each  N-t  is  defined  within  class  C,.   In 

order  for  the  mapping  to  make  sense,  the  following  must  be  true  for  any  attribute 


■70- 


i  within  the  mapping: 
1.     VCyt  3  C,+1  for  all  i  =  1.2,....m-l 

Finally,  the  last  part  of  a  base  class  definition  is  the  base  class  identifiers.  The  base 
class  identifiers  can  be 

i.    no  identifiers, 

11.    a  single  attribute  identifier  list  separated  by  plus  (+)  signs,  or 

ill.    multiple  attribute  Identifier  lists  separated  by  commas. 

The  productions  denning  the  identifier  declarations  are  then: 

<ident-ded>    ::-  IDENTIFIERS:  <ident-list>    I 
IDENTIFIERS  :  NONE 

<ident-list>    ::-    <  identifier  >    I 

<  idem-list  >  ,  <  identifier  > 

<  identified    :>  ATTRIBUTE_NAME  I 

<  identifier  >  +  ATTRIBUTE_NAME 

The  following  semantic  checks  will  be  made  for  the  identifier  declaration: 
Production: 

<ident-decl> >    identifiers:  <ident-list> 

Checks: 


i.    class  C  cannot  specify  that  duplicates  are  allowed  (since  a  unique 
member  specification  is  given). 


Production: 


<  identifier  >   — >   A^ 

<  identifier  > >    <  identifier  >+  .A  j 


Checks: 
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i.    A !  must  be  denned  as  a  member  attribute  within  class  C 
The  next  topic  for  discussion  is  the  construction  of  a  nonbase  class  dennition.   As 
in  the  dennition  of  the  base  class,  nonbase  classes  are  made  up  of  a  primary  class 
name  and  possible  synonymous  names,  followed  by  a  nonbase  class  body. 

<nonbase-class-def>    :>    <  class-name-list  > 
<  nonbase-class-body  > 

The  nonbase  class  body  is  made  up  of  an  optional  description  clause  (like  that  of 

the   base    class),    a    mandatory    interclass   connection,    and    the    nonbase    class 

alternatives. 

<  nonbase-class-body  >    ::-    <desc-clause> 

<  interclass-connection  > 

<  non  base-class-alts  > 

<nonbase-class-alts>    ::-    <nonbase-class-feat>    I 

<  name-class-feat  > 

The  nonbase  class  alternatives  will  identify  the  nonbase  class  as  a  definite  name 
class  (if  the  determines  clause  or  the  constant  members  clause  is  specified)  or  a 
possible  name  class.  A  possible  name  class  will  be  later  identified  as  a  name  class 
if  the  class  is  specified  as  a  subclass  of  one  of  the  built-in  classes  and  either  the 
user-controllable  subclass  predicate  or  no  subclass  predicate  is  specified.  A  name 
class  grouping  predicate  also  identifies  the  nonbase  class  as  a  name  class. 

Nonbase  class  features  allow  non-name  classes  to  be  given  member  attributes 
and/or  class  attributes.  Here  (as  opposed  to  base  class  definitions),  nonbase  class 
member  attribute  definitions  are  optional. 
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interclass  connection  specifies  how  this  subclass  derivation  is  determined.  The 
interclass  assertion  is  declared  as  follows: 

<interclass-assertion>    ::-  INTERCLASS  CONNECTION  : 
<  connection  >  <  ic-assertion-decl> 

where  the  connection  establishes  the  interclass  connection. 

With  the  interclass  connection,  zero  of  more  interclass  assertions  can  be  provided. 
The  interclass  assertion  simply  states  additional  interclass  connections  which  must 
be  satisfied  by  the  nonbase  class  member  list.  With  the  interclass  assertion  list,  a 
failure  action  can  be  specified.  This  failure  action  is  the  same  as  that  of  the 
attribute  assertion  failure  action.  The  interclass  assertion  declaration  is  as  follows: 

<ic-assertion-decl>    :>  6  I 

<ic-assertion-list>  <failure-action-clause> 

<ic-assertion-list>    :>    <  ic-assertion  >    I 
<ic-assertion-list>   <  ic-assertion > 

<  ic-assertion  >    ::-  INTERCLASS  ASSERTION  :<  connection  > 

An  interclass  connection  can  be  either  a  subclass  connection  (specifying  a  subclass 
of  the  parent  class)  or  a  grouping  connection  (grouping  the  members  of  the  parent 
class  In  some  way). 

<  connection  >    ::-    <subclass-connection>    I 

<grouping-connection> 

An  important  side  effect  of  establishing  a  grouping  connection  is  the  automatic 
definition  of  the  derived  multivalued  member  attribute  Contents,  whose  value  class 
is  the  parent  class.  The  "Contents"  attribute  has  as  its  value  for  a  given  member  of 
the  grouping  class,  all  members  of  the  parent  class  which  belong  to  one  of  the 
given  groupings. 
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The  first  type  of  interclass  connection  is  the  subclass  connection.  The  nonbase  class 
is  established  as  a  subclass  of  the  parent  class  by  application  of  a  subclass 
predicate  on  members  of  the  parent  class. 

<subclass-connection>    :>  SUBCLASS  OF  CLASS_NAME 

<  subclass-predicate  > 

Attributes  and  classes  referenced  in  the  <subclass-predlcate>  must  satisfy 
semantic  checks  consistent  with  the  definition  of  the  parent  class  PC  (see  subclass 
predicate  discussion  below). 

The  second  type  of  Interclass  connection  is  the  grouping  connection.  A  grouping 
connection  can  be  established  using  any  one  of  four  methods:  (1)  expression  defined 
grouping  class,  (2)  enumerated  grouping  class,  (3)  user-controllable  grouping  class, 
or  (4)  name  class  grouping  class. 

< grouping-connection >    ::=    <expression-defined-gc>    I 
<enumerated-gc>    I 

<  user-controllable-gc  >    I 

<  name-class-gc  > 

The  subclass  predicate  of  the  subclass  connection  allows  definition  of  several  types 
of  subclasses:  (1)  attribute-defined  subclass,  (2)  user-controllable  subclass,  (3) 
set-operator  defined  subclass,  (4)  existence  subclass,  or  (5)  name  class  subclass. 

<  subclass-predicate  >    ::-  WHERE  < attribute-predicate  >    I 
WHERE  SPECIFIED  I 
WHERE  <set-oper-deflned-sc>    I 
WHERE  <existence-sc>    I 
<  name-class-sc  > 

Attribute  mappings  referenced  in  the  <attribute-predicate>  of  the  attribute- 
defined  subclass  must  satisfy  semantic  checks  consistent  with  the  definition  of  the 
parent  class  PC.  The  attribute-defined  subclass  and  the  user-controllable  subclass 
C  will  inherit  all  member  attributes  defined  in  the  parent  class  PC. 
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The  set-operator  defined  subclass  defines  the  class  C  to  be  all  members  of  the 
parent  class  PC  which  satisfies  an  intersection,  union,  or  difference  of  two  classes. 

<set-oper-defined-sc>    :>  IS  IN  CLASS_NAME  AND 

IS  IN  CLASS_NAME  I 
IS  IN  CLASS_NAME  OR 

IS  IN  CLASS_NAME  I 
IS  NOT  IN  CLASS_NAME 

The  semantic  checks  which  will  be  performed  for  the  set-operator  defined  subclass 

are  as  follows: 

Production: 

<set-oper-defined-sc> >    is  in  C[  and  is  in  C2 

<set-oper-defined-sc> >    is  in  Ci  or  is  in  C2 

<set-oper-defined-sc> >    is  not  in  Ci 

Checks: 

i.    UCi  =  Ux 

11.    UCj  =  uK ,  if  c2  specified 
The  attribute  inheritance  rules  for  the  set-operator  defined  subclass  are  as  follows: 

a.  the  intersection  defined  subclass  C    will  inherit  all  member  attributes 
common  to  Ci  and  C2 

b.  the  union  defined  subclass  C  will  inherit  all  member  attributes  of  both  C, 
andc2 

c.  the  difference  defined  subclass  C  will  Inherit  all  member  attributes  of  the 
parent  class  PC 

The  existence  subclass  specifies  the  class  C  to  be  all  members  of  the  parent  class 
PC  which  is  currently  a  value  of  some  member  attribute  A  x  of  class  Cx. 
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<existence-sc>    ::-  IS  A  VALUE  OF  ATTRIBUTE_NAME 
OF  CLASS_NAME 

The  existence  subclass  C  will  inherit  all  member  attributes  of  its  parent  class  PC. 

The  semantic  checks  which  will  be  performed  for  the  existence  subclass  definition 

are  as  follows: 

Production: 

<  existence-sc  >   — >    is  a  value  of  A !  of  C ! 

Checks: 

i.    A  j  is  defined  as  a  member  attribute  within  class  C^ 

il.    VCAl=PC 
A  name  class  definition  can  either  (a)  not  specify  a  subclass  predicate,  or  (b) 
specify  a  format  directive  on  class  STRINGS. 

<name-class-sc>    ::-  6  I 

WHERE  FORMAT  IS  <format-directive> 

The  parent  class  PC  of  a  name  class  must  be  one  of  the  built-in  classes;  therefore, 

no  member  attribute  inheritance  is  involved.   The  semantic  checks  which  will  be 

performed  on  a  name  class  specification  are  as  follows: 

Production: 

<name-class-sc>   — >    e 
Checks: 

i.    PC  =  STRINGS,  NUMBERS,  REALS,  or  INTEGERS 
Production: 

<  name-class-sc  > >    where  format  is  <  f ormat-d  irective  > 

Checks: 

i.    PC  m  STRINGS 
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The  first  type  of  grouping  connection  was  the  expression  denned  grouping 
connection.  This  type  of  grouping  connection  defines  the  class  C  to  be  a  grouping 
of  the  parent  class  PC  based  on  common  values  of  one  or  more  attributes  of  PC . 

<rapression-defined-gc>    ::«  GROUPING  OF  CLASS_NAME 
ON  COMMON  VALUE  OF 
<attr-name-list> 
<  explicitly-def-grps  > 

<«plicitly-def-grps>    ::=  GROUPS  DEFINED  AS  CLASSES 
ARE  <class-name-list> 

Any  groups  of  members  of  the  parent  class  PC  which  are  also  explicitly  defined  as 

attribute-defined  subclasses  are  listed.   These  groupings  represent  redundant  class 

definitions,  one  within  the  grouping  defined  and  the  other  explicitly  defined  as  a 

subclass  of  PC.  The  semantic  checks  which  will  be  performed  for  the  expression 

denned  grouping  connection  are  as  follows: 

Production: 

<expression-defined-gc> >    grouping  of  PC  on  common  value  of  Ak 

<  explicitly-def-grps  > 

Checks: 

i.    At  must  be  defined  as  a  member  attribute  of  PC  for  all  k 
The  next  type  of  grouping  connection  is  the  enumerated  grouping  connection.  The 
enumerated  grouping  connection  defines  the  class  C  as  a  grouping  of  classes  Ck . 

<enumerated-gc>    ::-  GROUPING  OF  CLASS_NAME  CONSISTING 
OF  CLASSES  <class-name-list> 

The  semantic  checks  which  will  be  performed  for  the  grouping  connection  are  as 
follows: 
Production: 

<enumerated-gc> >    grouping  of  PC  consisting  of  classes  Ct 
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<nonbase-class-feat>    ::-   <nbc-member-attr-decl> 
<  class-attr-decl> 

<nbc-member-attr-decl>    :>  6  I 

<  member-attr-decl  > 

As  mentioned  earlier,  name  class  features  Include  the  determines  clause  and  the 
constant  member  clause. 

<  name-class-feat >    ::-    <  determines-clause  >    I 

<  const-members-clause  >    I 

<  determines-clause  >  <  con  st-members-clause  > 

<  determines-clause  >    ::-  determines:  CLASS_NAME 

<  const-members-clause  >    ::-  constant  members: 

<const-members-list> 

<const-members-list>    ::-  CONST_MEMBER_NAME  I 

<  const-members- list  >  <  comma-and-sep  > 

CONST_MEMBER_NAME 

The  determines  clause  allows  the  dependence  of  the  value  class  of  the  specified 
class  name  upon  a  value  of  the  given  name  class.   That  is,  a  value  of  this  name 
class  determines  the  value  class  of  the  specified  name  class.  The  semantic  checks 
which  will  be  performed  for  the  above  productions  follows: 
Production: 

<  determines-clause  >   — >    determines:  C  x 
Checks: 

i.    the  name  class  definition  for  d  must  be  defined  as  a  grouping 
name  class  "where  specified  by  C" 

ii.    C  must  contain  the  user-controllable  interclass  connection 

The  interclass  connection  is  what  distinguishes  a  base  class  from  a  nonbase  class  in 

the  SDM  schema.  The  members  of  a  nonbase  class  are  eventually  derived  from  the 

members  of  the  underlying  base  class.   This  derivation  could  be  directly  from  a 

base  class  or  indirectly  through  a  series  of  nonbase  subclass  definitions.    The 
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Checks: 

i.    UCt  =  UK  for  all  * 

The  user-controllable  grouping  class  allows  the  user  to  specify  the  grouping  of  the 
parent  class  PC . 

<user-controllable-gc>    ::-  GROUPING  OF  CLASS_NAME 
AS  SPECIFIED 

No  semantic  checks  are  required  for  the  user-controllable  grouping  connection. 

The  name  class  grouping  connection  allows  the  database  designer  to  specify  the 
name  class  as  a  grouping  of  value  class  definitions;  the  value  class  group  being 
determined  by  the  value  of  another  class  Ct.  Both  Cx  and  C  must  be  user- 
controllable  connections  to  keep  the  grouping  connection  at  a  finite  (and  user 
controllable)  level. 

<name-class-gc>    ::-  GROUPING  OF  CLASS_NAME  AS 
SPECIFIED  BY  CLASS_NAME 

The  semantic  checks  which  will  be  made  for  the  name  class  grouping  connection 

are  as  follows: 

Production: 

<  name-class-gc  >    — >    grouping  of  PC  as  specified  by  C  t 
Checks: 

i.    Class  definition  for  Cj  must  contain  "determines:  C"  clause 
11.    C2  =  STRINGS,  NUMBERS,  REALS,  or  INTEGERS 
The  attribute  predicate  used  within  the  attribute-defined  subclass  definition  and 
the  subvalue  derivation  predicate  will  now  be  discussed.  The  attribute  predicate  is 
a  boolean  expression  which  relates  mappings  denned  within  the  defining  class  C 
with  (1)  constant  values,  (2)  other  mappings  within  C,  or  (3)  members  of  other 
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classes.  The  production  sequence  for  the  attribute  predicate  is  as  follows: 

< attribute-predicate >    ::-    <attr-pred-term>    I 

<  attribute-predicate  >  OR  <attr-pred-term> 

<attr-pred-term>    :>   <attr-pred-f actor  >    I 

<attr-pred-term>  AND  <attr-pred-f actor  > 

<attr-pred-f actor >    ::-    <attr-pred-primary>    I 
NOT  <attr-pred-primary> 

<attr-pred-primary>    ::=  (  < attribute-predicate >  )  I 
<simple-predicate> 

<  simple-predicate  >    :>    <relop-predicate>    I 

<  setop-predicate  > 

<relop-predicate>    ::-    <mapping>  <relop>  <constant>    I 

<  mapping  >  <relop>  <  mapping  > 

< setop-predicate >    :>   <mapping>  <setop>  <constant>    I 

<  mapping  >  <setop>  <  mapping  >    I 
<mapping>  <setop>  CLASS_NAME 

<relop>    ::-  -  I  -I  <  I  <_|  >  |  >» 

<setop>    ::-  IS  <properly>  CONTAINED  EM  I 
<  properly  >  CONTAINS 

<  properly >   :>  PROPERLY  I  e 

The  boolean  operator  precedence  (NOT  then  AND  then  OR)  has  been  built  into  the 
SDML    grammar.     The    semantic    checks    which    will    be    performed    for    the 
productions  which  make  up  the  attribute  predicate  are  as  follows: 
Production: 

<relop-predicate> >    AM  i  <relop>   <  constant  > 

Checks: 

1.    CAM  !>  '  must  be  defined  as  a  member  attribute  of  C 

11.  Define  Ct  as  the  value  class  of  AMlt  and  type(  <  constant>  )  as 
the  type  of  the  nonterminal  <constant>  (STRING  C  REAL  C 
orINTEGER_C).  Then:  "'  KEAL-<- 


80- 


a.  If  typeC  <  constant>  )  =.  STRING_C  then  Uc ,  =  STRINGS 

b.  otherwise,  Uc%  =  NUMBERS,  INTEGERS,  or  REALS 
Production: 

<relop-predicate> >    AMi  <relop>  AM2 

Checks: 

i.    (AM, )  '  must  be  defined  as  a  member  attribute  of  C  for  £  =  1,2 

ii.    Given  that  C,  is  the  value  class  of  AM,  for  £  =  1,2,  then  Uc   = 
STRINGS,  NUMBERS,  INTEGERS,  or  REALS 

ill.    UCl  =  UCl 

Production: 

<setop-predicate>    — •    AMt  <setop>   <constant> 
Checks: 

i.    (AMi)  '  must  be  defined  as  a  member  attribute  of  C 

ii.    Since  <constant>   denotes  a  single  string  or  numeric  constant 
then  <setop>  must  be  the  "[properly]  contains"  set  operation. 

ill.    Letting  C !  be  the  value  class  of  AM  lF  then: 

a.  If  type(  <  constant> )  -  STRTNG_C  then  Uc   =  STRINGS 

b.  otherwise,  UCl  =  NUMBERS,  INTEGERS,  or  REALS 
Production: 

<setop-predicate> >    AM \  <setop>  AMi 

Checks: 

i.    (AMt )  '  must  be  defined  as  a  member  attribute  of  C  for  t  =  1.2 

ii.    Given  that  C,  is  the  value  class  of  AM,  for  £  =  1,2,  then  Ur   =  K. 

ci  c2 

Production: 

<setop-predicate>   — >    AMX  <setop>  d 
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Checks: 

i.  (.AM  J  '  must  be  denned  as  a  member  attribute  of  C 

ii.  Denning  C2  as  the  value  class  of  AM,,  then  Ur   m  Ur 
Production: 

<setop> 1    is  <properly>  contained  in 

Checks: 

1.    If  RHS  of  <setop>   is  an  attribute  mapping,  then  it  must  be  a 
multivalued  attribute  mapping 

Production: 

<setop> >    <properly>  contains 

Checks: 

i.  LHS  (AM 0  must  be  a  multivalued  attribute  mapping. 
The  format  directive  allows  the  database  designer  to  provide  a  template  for  data  to 
be  entered  for  a  given  name  class.  With  the  format  directive,  comes  a  variety  of 
constructs  which  can  be  used  to  specify  the  subunits  of  the  domain  and  place 
restrictions  on  these  subunits.  The  format  directive  used  in  the  SDML  grammar  is 
a  modified  version  of  the  Domain  Definition  Language  (DDL)  outlined  in  reference 
[13]. 

The  format  directive  for  a  name  class  definition  contains  three  distinct  parts:  (1) 
description  clause,  (2)  ordering  clause,  and  (3)  violation  action  clause. 

<  format-directive >    ::-   <description-clause> 

<  ordering-clause> 

<  violation-actn -clause  > 

The  description  clause  allows  for  several  alternative  domains  for  the  format  of  the 
name  class.  Thus,  each  possible  domain  is  specified  in  an  "or"-list. 
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<  description-clause  >    ::-   <description-subclause>    I 

<  description-clause  >  OR  <description-subclause> 

The  description  subclause  specifies  one  of  the  possible  domains  for  the  format  of 
the  name  class.  The  description  subclause  is  made  up  of  the  description  of  the 
domain  followed  by  any  restrictions  placed  on  subunits  of  the  domain.  The 
restrictions  placed  on  the  subunits  of  the  domain  is  termed  the  global  where 
restriction. 

<description-subclause>    ::-   <description>  .  I 

<  description  >  .  <where-restriction>  . 

Here,  additional  syntax  (comma's  and  period-s)  was  added  to  the  DDL  grammar 
provided  in  reference  [13]  to  resolve  conflicts  resulting  from  the  DDL  grammar 
being  non-LRCl).  The  conflict  arises  because  the  parser  cannot  distinguish  the  "or" 
in  the  <where-restrlctlon>  from  the  "or"  separating  the  <descriptlon-subclause> 
nonterminals  in  the  <  description-clause>  production. 

The  description  for  a  domain  defines  the  subunlfs  which  constitute  the  domain. 
The  subunlfs  which  make  up  the  domain  are  separated  by  comma's. 

<description>    :>   <subunit>    I 

<  description  >  .  <subunit> 

A  subunlt  is  identified  by  an  optional  label.  Use  of  the  label  allows  this  particular 

subunit  of  the  domain  to  be  used  in  the  restriction  clause  as  part  of  the  domain 

definition.   If  the  label  is  omitted,  this  subunlt  cannot  be  referenced  further.   The 

scope  of  a  subunlt  label  is  only  within  the  current  domain  definition. 

<subunit>    ::-    <subunit-item>    I 
LABEL  :  <subunit-item> 

The  subunlt  Item  can  be  defined  to  be  any  one  of  the  following: 
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1.  Subset  of  strings  with  an  optional  constraint  on  the  strings  allowed,  subunit 
where  restriction. 

2.  Subset  of  numbers  with  an  optional  constraint  on  the  numbers  allowed. 

3.  An  enumeration  of  string  constants  or  types.   The  possible  types  of  strings 
are  alphabetics,  numerics,  and  specials. 

4.  An  enumeration  of  number  constants. 

5.  A  string  constant. 

If  only  one  enumeration  is  given,  no  parenthesis  are  required.  If  two  or  more 
enumerations  are  given,  they  must  be  enclosed  in  parenthesis.  The  restrictions 
placed  on  the  subset  of  subunit  values  is  termed  the  subunit  where  restriction.  The 
productions  which  define  the  subunit  definition  follows: 

<subunit-item>    ::-  STRING  <str-where-clause>    I 
NUMBER  <num-where-clause>    I 
ONEOF  <  string-list  >    I 
ONEOF  <number-list>    I 
STRING_C 

<str-where-clause>    ::«  e  I 

WHERE  <  string-boolean  > 

<num-where-clause>    :>  e  I 

WHERE  <  number-boo  lean  > 

<string-list>    ::-   < string-component >   I 

(  <string-list>  .  <string-component>  ) 

<  string-component  >    ::-  STRING_C  I 
ALPHABETICS  I 
NUMERICS  I 
SPECIALS 

<number-list>    ::-    <number>    I 

(  <  number-list  >  .  <  number  >  ) 
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The  boolean  expression  which  restricts  the  subset  of  strings  in  the  subunit  where 
restriction  is  described  next.  The  predicates  of  the  boolean  expression  are  the 
typical  boolean  operations  "and",  "or",  and  "not"  as  well  as  an  "If-then-else" 
construct.  The  conditions  of  the  boolean  expression  are  the  following: 

1.  A  lexicographic  comparison  of  the  subunit  with  a  string  constant. 

2.  A  scalar  comparison  of  the  size  of  the  subunit  with  an  integer  constant 
("size"  operator). 

3.  A  boolean  condition  which  evaluates  to  "true"  if  any  one  of  a  number  of 
given  string  components  are  found  within  the  subunit  ("has"  operator). 

4.  A  boolean  user-defined  function  which  supplies  a  value  of  "true"  or  "false". 

The  productions  which  make  up  the  string  subunit  where  restriction  follows: 

< string-boolean >    ::-    <string-bool-term>    I 

<  string-boolean  >  OR  <string-bool-term> 

<string-bool-term>    ::-    <string-bool-factor>    I 

<string-bool-term>  AND  <  string-bool-f actor  > 

<string-bool-f  actor  >    ::-    <string-bool-primary>    I 
NOT  <string-bool-primary> 

<string-bool-primary>    :>  (  <  string- boolean  >  )  I 
<  string-predicate  > 

< string-predicate >    :>    <string-condition>    I 

IF  < string-condition >  THEN  <string-predicate>  FI  I 
IF  <  string-condition  >  THEN  <string-predicate> 
ELSE  <  string-predicate  >  FI 

<  string-condition  >    ::-    <relop>  STRING_C  I 
SIZE  <relop>  INTEGER_C  I 
HAS  <string-list>    I 
CALL  PROCEDUREJVAME 

Notice  that  the  precedence  of  the  boolean  operators  is  built  in  to  the  SDML 
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grammar. 

The  boolean  expression  which  restricts  the  subset  of  numbers  in  the  subunit  where 
restriction  is  described  next.  The  predicates  of  the  boolean  expression  are  the 
typical  boolean  operations  "and",  "or",  and  "not",  an  integer  and  real  restriction,  and 
an  "if-then-else"  construct,  .  The  conditions  of  the  boolean  expression  are  the 
following: 

1.  A  scalar  comparison  of  the  subunit  with  a  numeric  constant. 

2.  A  boolean  user-defined  function  which  supplies  a  value  of  "true"  or  "false". 
The  productions  which  make  up  the  number  subunit  where  restriction  follows: 

<  number-boolean  >    :>    <  number-boo l-term>    I 

<  number-boolean  >  OR  <number-bool-term> 

<number-bool-term>    ::-    <number-bool-factor>    I 

<number-bool-term>  AND  <number-bool-f actor > 

<number-bool-factor>    :>   <  number-boo l-primary>    I 
NOT  <number-bool-primary> 

<number-bool-primary>    ::-  (  <  number-boolean >  )  I 
<number-predicate> 

<  number-predicate >    ::-    <  number-condition >    I 

IF  < number-condition >  THEN  <number-predicate>  FI  I 
IF  < number-condition >  THEN  <number-predicate> 

ELSE  <  number-predicate  >  FI  I 
INTEGER  I 
REAL 

<  number-condition  >    :>   <relop>  <  number  >    I 

CALL  PROCEDURE_NAME 

Based  on  the  SDML  grammar  definitions  of  the  number  and  string  subunit  where 
restrictions,  it  can  be  seen  that  no  additional  type  checking  is  needed  for  these 
constructs.  All  type  checking  here  is  forced  in  the  SDML  grammar  itself. 


-86- 


Now  for  the  definition  of  the  global  where  restriction.  The  global  where 
restriction,  like  the  subunit  where  restriction,  is  a  boolean  expression  which 
restricts  the  domain  definition  as  a  whole.  Any  labels  given  to  subunits  within  the 
subunit  definitions  can  be  referenced  within  the  global  where  restriction.  The  same 
constructs  apply  to  the  global  where  restriction  as  in  the  string  subunit  where 
restriction.  The  conditions  which  can  be  used  within  the  global  where  restriction 
are  as  follows: 

1.  A  boolean  expression  representing  a  scalar  or  lexicographic  comparison 
between  two  subexpressions.  The  type  of  comparison  depends  upon  the  type 
of  primitives  used  within  the  subexpressions. 

2.  A  boolean  "present"  operator  which  returns  "true"  if  a  second  substring  is 
contained  within  the  first. 

3.  A  boolean  user-defined  function  which  supplies  a  value  of  "true"  or  "false". 

The  productions  which  begin  the  construction  of  the  global  where  restriction  are  as 
follows: 
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<where-restriction>    ::=  WHERE  <boolean> 

<boolean>    ::-    < boolean- term >    I 

<  boolean  >  OR  <  boolean- term  > 

< boolean- term >   ::-   <boolean-factor>    I 

<  boolean- term >  AND  <boolean-factor> 

<boolean-factor>   ::-   <  boolean-primary >   I 
NOT  <  boolean- primary > 

< boolean-primary >    ::-  (  <boolean>  )  I 
<  predicate  > 

<  predicate  >    ::-    <  condition  >    I 

IF  <condition-expr>  THEN  <  predicate  >  FI  I 
IF  <condition-rapr>  THEN  <  predicate  > 
ELSE  <  predicate  >  FI 

<  condition  >    ::-    <  expression  >  <relop>  <  expression  >    I 

PRESENT  (  <expression>  .  <expression>  )   I 
CALL  PROCEDURE_NAME 

Since  the  expressions  referenced  in  the  global  where  restriction  can  evaluate  to 

either  strings  or  numerics,  some  type  checking  is  required  to  verify  the  semantics. 

As  previously  denned,  the  type  of  nonterminal  "expression"  will  be  denoted  as 

"type«expression> )".  The  following  type  checks  will  be  performed  to  the  above 

production  rules  (where  £,  is  expression  number  i ): 

Production: 

<condition> >    <Ei>  <relop>  <E2> 

Checks: 

i.    typeC  <£j>  )  -  type(  <E3>  ) 
Production: 

<condition> >    present  (  <Et>.  <E2>  ) 

Checks: 

i.    type(  <Ei>  )  -  "string" 
ii.    type(  <E2>  )  -  "string" 
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Some  boolean  operators  were  added  to  the  condition  of  the  if -then-else  statements 
for  the  global  where  restriction  which  were  missing  from  the  grammar  presented  in 
reference  [13].  The  condition  expression  for  the  if-then-else  can  then  be  a  boolean 
expression  involving  the  conditions  of  the  global  where  restriction.  The 
productions  for  the  condition  expression  are: 

<condition-expr>    :>    <condition-term>    I 

<condition-expr>  AND  <  condition-term  > 

<  condition-term >    ::-   <  condition- f actor  >    I 

<  condition-term >  OR  <condition-factor> 

<  condition-factor >    ::-   (  <  condition-expr  )   I 

<  condition  > 

In  case  expressions  involve  numeric  terms,  a  construct  for  building  arithmetic 
expressions  has  been  provided. 

<  expression  >    :>    <  arithmetic-term  >    I 

<  expression  >  <  addition-operator  >  <  arithmetic-term  > 

<  arithmetic-term  >    ::-   <  arithmetic-factor  >    I 

<  arithmetic- term  >  <multiply-operator>  <  arithmetic-factor  > 

< arithmetic-factor >    ::-   <arithmetic-primary>   I 

<  arithmetic-factor  >  <  exponent-operator  >  <  arithmetic-primary  > 

< arithmetic-primary >    :>  (  <expression>  )  I 
<  subexpression  > 

If  an  expression  is  a  string  constant,  none  of  the  production  alternatives  involving 

the  arithmetic  operators  should  be  allowed.   Therefore,  the  following  type  checks 

will  be  performed  for  the  above  productions: 

Production: 

<E>   — '    <E>  <add-op>  <T> 
Checks: 

1.    type(  <£>)-  "numeric" 
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11.    type(  <T>  )-  "numeric" 
Production: 

<T> ►    <T>  <mult-op>  <F> 

Checks: 

i.    type(  <r>  )- "numeric" 
ii.    type(  <F>  )-  "numeric" 
Production: 

<F>   — >    <F>  <eip-op>  <P> 
Checks: 

1.    typeC  <F>  )- "numeric" 
ii.    typeC  <i>>  )- "numeric" 
The  subexpression  definition  supplies  the  following  functions  which  can  be  applied 
to  string  or  numeric  terms: 

1.    Specification  of  an  atomic  expression,  which  represents  an  individual  item. 
The  types  of  atomic  expressions  which  can  be  specified  are: 

a.  A  subunit  label  which  is  defined  within  this  domain  description. 

b.  A  string  constant. 

c.  A  (positive  or  negative)  numeric  constant. 

d.  The  star  (*)  operator.  A  star  represents  the  current  value  of  the 
domain  being  checked  (i.e.,  the  users  input  which  is  being  checked  for 
validity). 

2.    The  minimum,  maximum,  sum,  or  average  of  a  list  of  expressions. 
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3.  The  result  of  appending  two  string  expressions. 

4.  The  substring  of  a  string  expression  between  two  given  points. 

5.  The  left  substring  of  a  string  expression. 

6.  The  right  substring  of  a  string  expression. 

7.  The  location  of  one  string  within  another. 

8.  The  length  of  a  string  expression. 

9.  Repeated  applications  of  a  subunit  range  to  the  domain  definition.  This 
alternative  allows  a  subunit  range  to  be  repeated  some  number  of  times 
when  considering  the  domain  of  the  name  class. 

The  productions  which  specify  the  subexpression  options  are: 

<  subexpression  >    :>    <  atomic-expression  >    I 

<  set-function >  (  <  expression-list  >  )  I 
APPEND  (  <  expression  >  ,  <  expression  >  )  I 
SUBSTRING  (  <  expression  >  .  <char-pos>  . 

<char-pos>  )  I 
LEFT  (  <expression>  ,  <char-pos>  )  I 
RIGHT  (  <  expression  >  .  <char-pos>  )  I 
LOCATION  (  <  expression  >  ,  <  expression  >  )  I 
LENGTH  (  <  expression  >  )   I 
REPETITIONS  LABEL  THROUGH  LABEL 

<  atomic-expression  >    ::-  LABEL  I 

STRTNG_C  I 

<  number  >    I 

<  addition-operator  >   <  number  >    I 

* 

< expression-list >    ::-   <expression>    I 

<  expression-list  >  .  <  expression  > 

The  type  checks  which  will  be  performed  for  the  above  productions  are  as  follows: 
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Production: 

<  subexpression  >    — >    <  set-function  >  (  <Et  >  ) 
Checks: 

i.    typeC  <£,  >  )  -  "numeric"  for  all  i  In  * 
Production: 

<subexpression> >    append  (  <£!>,  <E2>  ) 

Checks: 

i.    typeC  <£!>  )- "string" 
11.    type(  <E2>  )  -  "string" 
Production: 

< subexpression > •    substring  (<£>,  <CPl>,  <CP2>  ) 

Checks: 

1.    typeC  <E  >  )  -  "string" 
Production: 

<subexpression> >    left  (<£>.  <CP  >  ) 

Checks: 

1.    typeC  <E  >  )  -  "string" 
Production: 

< subexpression >    —- •    right  (<£>,  <CP  >  ) 
Checks: 

i.    type(  <E>  )- "string" 
Production: 

< subexpression > >    location  (<£,>.  <E2>  ) 

Checks: 

i.    type(  <Et>  )  -  "string" 
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U.    type(  <E2>  )  =  "string" 
Production: 

< subexpression »    length  (  <E>  ) 

Checks: 

i.    typeC  <£>)  =  "string" 
The  <char-pos>  nonterminals  (and  the  Ci>,  's)  describe  a  character  position  within 
a  string.  The  character  position  could  be:  (1)  the  location  of  a  substring  within  the 
string,  (2)  the  location  of  a  substring  offset  by  an  integer  constant  within  the 
string,  or  (3)  an  integer  constant  defining  a  character  position  within  the  string. 

<char-pos>    ::-  STRING_C  I 

STRTNG_C  <  addition-opera  tor  >  INTEGER_C  I 
INTEGER_C 

The  second  part  of  the  format  directive  is  the  ordering  clause.  This  is  an  optional 
specification  of  how  the  elements  of  the  domain  will  be  ordered: 

1.  via  a  specified  list  of  subunit  labels, 

2.  no  ordering  will  be  done, 

3.  atomic  ordering  will  be  done;  that  is,  lexicographic  ordering  will  take  place, 
or 

4.  via  a  user-defined  function. 

The  following  productions  define  the  ordering  clause  for  the  format  directive: 
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<ordering-clause>    :>  e  I 

ORDERING  :  <ordering> 

<ordering>    ::-   <ordering-list>    I 
NONE  I 
ATOMIC  I 
CALL  PROCEDURE_NAME 

<ordering-list>    :>  LABEL  I 

<ordering-Hst>  ,  LABEL 

Finally,  a  violation  action  can  be  specified,  which  will  determine  the  action  taken 

when  data  is  entered  which  does  not  conform  to  the  domain  specification.   Either 

an  error  can  be  flagged  Cand  an  optional  message  printed)  or  a  user-defined  function 

can  be  called  to  determine  the  course  of  action.  Thus,  the  productions  which  define 

the  violation  action  clause  for  the  domain  definition  are  as  follows: 

<  violation-actn -clause >    ::=  e   I 

VIOLATION  ACTION  :  <violation-action> 

<violation-action>    ::-  ERROR  <  action-message >    I 
CALL  PROCEDURE_NAME 

<  action-message >    ::-  STRING_C  I   6 

The  final  productions  in  the  SDML  grammar  define  the  number  and  constant 
nonterminals  used  within  the  rest  of  the  SDML  grammar.  A  number  is  an  integer 
or  real  constant.  A  constant  is  a  string  constant  or  a  number  constant.  A  constant 
also  could  be  a  CONST_MEMBER_NAME  representing  a  string  constant  or  a 
number  constant. 

<number>    ::-  INTEGER_C  I  REAL_C 

<  constant  >    ::-  STRING_C  I 

<number>   I 
CONST_MEMBER_NAME 
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5.4  Summary 

This  chapter  has  presented  the  design  of  the  SDML  grammar  for  the  SDM  model 
described  in  Chapter  2,  with  extensions  added  which  were  described  in  Chapter  3. 
Also  presented  were  the  semantic  checks  necessary  which  would  not  be  detected  by 
the  simple  syntax  checking  of  the  SDML  parser.  It  was  determined  that  some  type 
checking  within  expressions  was  also  necessary. 

Chapter  5  will  discuss  issues  Involving  the  design  of  a  parser  for  the  SDML 
grammar.  Also  discussed  will  be  the  data  structures  used  by  the  SDML  parser  to 
perform  a  complete  semantic  check  of  the  SDML  specification  being  parsed. 
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Chapter  5:  SDML  Parser  Implementation 

This  chapter  will  discuss  the  SDML  parser  for  the  grammar  presented  in  Chapter 
4.  The  structure  of  the  tables  used  by  the  parser  and  the  structure  of  the  parser 
output  will  also  be  discussed.  Before  getting  into  the  design  of  the  SDML  parser, 
however,  an  introduction  to  parser  theory  will  first  be  given. 

6.1  SDML  Parser  Theory 

To  allow  for  ease  of  implementation  of  the  SDML  parser,  the  Yacc  (Yet  Another 
Compiler-Compiler)  program  will  be  used  to  automatically  generate  a  parser  with 
the  desired  functionality.  Yacc  accepts  a  general  class  of  LR(l)  grammars  which 
may  or  may  not  contain  ambiguities.  Yacc  will  resolve  these  ambiguities  with 
disambiguating  rules.  Because  of  these  disambiguating  rules  and  the  parsing 
algorithm  which  Yacc  uses,  SDML  grammar  ambiguity  Is  not  a  concern  once  the 
grammar  is  accepted  by  Yacc  with  no  shift-reduce  or  reduce-reduce  conflicts 
reported. 

Yacc  generates  a  shift-reduce  parser  for  the  supplied  grammar.  The  following 
sections  will  describe  shift-reduce  parsing  theory  and  error  recovery  used  by  the 
Yacc  program. 

6.1.1  Shift-Reduce  Parser  Theory  A  shift-reduce  parser  Is  a  bottom-up  LR  parsing 
technique  which  reduces  an  input  token  stream  left-to-right  producing  a  rightmost 
derivation  in  reverse.  A  rightmost  derivation  is  achieved  by  replacing  the  rightmost 
nonterminal  at  every  derivation  step.  A  rightmost  derivation  is  also  referred  to  as 
a  canonical  derivation. 
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Using  the  rm  subscript  on  the  derivation  symbol  (->)  to  denote  a  rightmost 
derivation,  and  given  a  rightmost  derivation  sequence 

S»     =>'rm     <*. 

then  a  is  a  right-sentential  form  for  the  grammar  r. 

The  handle  of  a  right-sentential  form  a/3w  of  r  is  a  substring  0  of  a/3>v  such  that 

Ss  =>'rm  <*Aw  =>  aPw  and  A  -»  0, 
where  a^w  is  the  previous  right-sentential  form  and  we  X".  A  rightmost 
derivation  in  reverse  (also  called  a  canonical  reduction  sequence)  is  obtained  by 
handle  pruning.  Handle  pruning  is  the  act  of  building  and  reducing  handles  from 
the  input  token  stream.  In  a  canonical  reduction  sequence,  the  leftmost  handle  is 
located  and  reduced  to  form  the  previous  right-sentential  form.  This  single 
reduction  is  called  a  canonical  reduction  and  is  performed  as  follows: 

i.  Define  w  as  the  input  token  stream  which  is  to  be  parsed.  Thus  «/„  =  w 
represents  the  n'"  right-sentential  form  of  the  desired  canonical  derivation. 
The  desired  canonical  derivation  would  be  as  follows: 

S,  =  v0  =  >rm    Vlm>m     ...     .  >rm    Vj>_l   =>m    Vit  =  w. 
ii.    Locate  the  handle  0„  in  *„  and  replace  0„  by  the  LHS  of  some  production 
A„    -   0„  to  obtain  the  (it-1)"  right-sentential  form  »,_t. 

hi.  Repeat  step  (Uj  until  (assuming  a  successful  parse)  the  ff»  right-sentential 
form  (i.e.,  »„  =  5, )  is  found.  When  the  last  handle  can  be  replaced  with  the 
start  symbol,  a  successful  parse  is  accomplished. 

Parsers  which  perform  this  type  of  bottom-up  parsing  by  handle  pruning  are 
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called  shift-reduce  parsers  because  tokens  are  shifted  onto  the  token  stack  until  a 
handle  is  found,  when  the  handle  is  reduced  to  a  nonterminal  symbol  representing 
the  LHS  of  the  production  corresponding  to  the  handle  on  the  RHS. 

The  Yacc  program  performs  such  a  shift-reduce  parsing  algorithm.  Now  that  the 
basic  theory  behind  shift-reduce  LR  parser  algorithms  is  understood,  the  conflict 
and  error  recovery  capabilities  of  Yacc  will  be  discussed. 

6.1.2  Yacc  Grammar  Conflicts  and  Error  Recovery  Based  on  the  structure  of  the 
grammar  supplied  to  Yacc,  two  types  of  conflicts  may  arise:  (1)  shift-reduce 
conflicts  and  (2)  reduce-reduce  conflicts. 

Shift-reduce  conflicts  arise  when  the  parser  does  not  know  whether  to  shift  the 
current  input  token  onto  the  stack  as  part  of  a  handle  or  to  reduce  the  current 
handle  on  the  stack  using  one  of  the  grammar  rules.  Shift-reduce  conflicts 
typically  result  when  an  ambiguous  grammar  is  specified. 

Reduce-reduce  conflicts  arise  when  the  parser  does  not  have  enough  information  to 
select  one  of  two  grammar  rules  when  a  handle  can  be  reduced,  even  with  the 
current  look-ahead  token.  Reduce-reduce  conflicts  result  when  a  non-LR(l) 
grammar  is  supplied  to  Yacc. 

The  SDML  grammar  listed  in  Appendix  4  contains  no  shift-reduce  or  reduce-reduce 
conflicts. 

Yacc  provides  an  error  recovery  mechanism  in  case  of  an  error  in  parsing  the  input 
token  stream.  This  mechanism  uses  the  technique  of  discarding  input  tokens  until 
a  safe-point  is  reached  on  the  stack,  and  attempting  to  continue  parsing  from  that 
point.   Yacc  allows  the  grammar  to  include  a  special  terminal  symbol,  error,  which 
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defines  a  safe-point  for  the  grammar  (or  a  point  where  errors  will  most  likely 
occur).  When  the  Yacc  parser  detects  an  error  in  the  input  stream,  it  pops  its  stack 
until  a  safe-point  marker  is  reached  and  attempts  to  continue  from  that  point. 
Yacc  will  remain  in  an  error  state  until  three  tokens  have  been  successfully  read 
and  shifted  onto  the  rebuilt  stack. 

6.2  The  SDML  Parser 

The  SDML  parser  will  be  automatically  generated  by  the  Yacc  [15]  program. 
Within  the  Yacc  grammar  specification,  blocks  of  code  called  actions  are  supplied 
with  certain  grammar  rules  to  specify  some  action  to  take  when  the  given  handle  is 
found  and  reduced  using  that  particular  grammar  rule. 

The  Lex  [14]  program  will  automatically  generate  the  lexical  analyzer  which  will 
tokenize  the  input  stream  representing  the  SDML  specification.  Lex  wiU  pass  the 
next  token  from  the  input  stream  to  Yacc,  which  will  be  parsing  the  tokens 
received.  Additional  implementation  required  (besides  supplying  the  tokens  and 
grammar  to  Lex  and  Yacc  respectively)  will  be  to  supply  the  blocks  of  code  within 
the  Lex  and  Yacc  input  files  and  the  subroutines  used  by  these  blocks  of  code  to 
perform  the  actions  necessary  by  the  SDML  parser. 

The  SDML  parser  will  be  a  two-pass  parser.  Pass  1  of  the  parser  will  check  syntax 
(by  performing  an  LR(1)  parse  of  the  input  token  stream)  and  load  symbols  and 
constants  into  the  symbol  table.  Only  defined  (as  opposed  to  referenced)  class 
names,  attribute  names,  label  names,  and  constant  member  names  will  be  loaded 
into  the  symbol  table  during  pass  1.  The  reason  for  this  is  two-fold: 

1.    attribute  names  must  be  entered  in  the  symbol  table  with  the  underlying 
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base  class  as  part  of  the  key.  Therefore,  If  an  attribute  name  is  referenced 
before  it  is  defined,  the  reference  will  not  know  the  class  to  which  the 
symbol  belongs.  An  attributes  class  definition  when  referenced  depends  on 
the  context  in  which  the  attribute  appears.  This  attribute  definition  check 
will  be  done  by  the  parser  during  pass  2  of  the  compiler  as  part  on  the 
semantic  checks  for  the  reference. 

2.    undefined  symbol  references  during  pass  2  are  recognized  simply  by  their 
non-existence  in  the  symbol  table. 

To  make  the  code  consistent  for  all  symbol  type  definitions,  all  symbols  will  be 
handled  in  this  fashion.  Constant  symbols,  however,  have  no  basis  for  definition 
and  have  no  uniqueness  criteria  and  will,  therefore,  be  loaded  into  the  symbol 
table  when  recognized  on  pass  1  of  the  SDML  parser. 

The  following  sections  describe  the  various  aspects  of  the  SDML  parser  including 
symbol  table  administration,  semantic  checks,  and  parser  output. 

6.3  Restrictions 

The  major  restriction  enforced  by  the  SDML  parser  is  when  naming  class, 
attribute,  label,  procedure,  and  constant  member  names: 

•  Class  names  must  begin  with  an  upper-case  character  and  can  be  followed  by 
zero  or  more  upper-case  characters,  underscores,  or  digits. 

•  Attribute   names   must   begin   with   an   upper-case  character  and   can   be 
followed  by  one  or  more  lower-case  characters,  underscores,  or  digits. 
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•  Label  names  must  begin  with  a  lower-case  character  and  can  be  followed  by- 
zero  or  more  lower-case  characters,  underscores,  or  digits. 

•  Procedure  names  must  begin  with  an  underscore  and  can  be  followed  by  one 
or  more  lower-case  characters,  underscores,  or  digits. 

•  Constant  member  names  must  begin  with  an  underscore  and  can  be  followed 
by  one  or  more  upper-case  characters,  underscores,  or  digits. 

The  other  restriction  enforced  by  the  SDML  parser  is  that  all  eventual  parent 
classes  must  be  defined  prior  to  definition  of  a  member  attribute  for  a  nonbase 
class.  The  reason  for  this  restriction  is  so  the  uniqueness  condition  can  be  checked 
for  attribute  definition.  This  implies  that  the  underlying  base  class  for  the  class 
being  denned  is  known  so  that  it  can  be  entered  into  the  symbol  table  with  the 
attribute  name. 

6.3.1  The  Symbol  Table  The  symbol  table  for  the  SDML  parser  will  hold  all  label 
and  constant  symbols  recognized  by  the  lexical  analyzer.  Each  type  of  symbol 
which  can  be  loaded  into  the  symbol  table  must  be  unique  with  respect  to  some 
defined  scope.  Figure  6-1  lists  each  symbol  which  can  be  loaded  into  the  symbol 
table  and  its  scope  of  uniqueness  Cw.r.t.  means  with  respect  to). 


-  101 


Symbol  Type  Uniqueness 

Class  Name  w.r.t.  SDM  schema 

Attribute  Name  w.r.t.  Underlying  base  class 

Label  Name  w.r.t.  Description  subclause 

Procedure  Name  w.r.t.  SDM  schema 

Constant  Member  Name  w.r.t.  SDM  schema 

String  Constant  None 

Integer  Constant  None 

Real  Constant  None 

Figure  6-1.  SDML  Symbol  Types  and  Uniqueness 

To  implement  the  different  symbol  uniqueness  scopes,  the  symbol  table  key  will 

consist  of  three  elements:  (1)  symbol  type,  (2)  supplementary  key  data  (providing 

uniqueness),  and  (3)  symbol  name.   Figure  6-2  shows  the  layout  of  the  symbol 

table  key  with  the  size  (in  bytes)  of  the  item  in  parenthesis. 


I  type  (2)  I    sup_data  (4)    I  symbol  name  (80) 


Figure  6-2.  Symbol  Table  Key  Layout 
The  symbol  table  is  indexed  by  a  hash  table  which  is  kept  within  the  hsearch 
UNIX™  system  library  function.  Hsearch  provides  a  Knuth  Algorithm  D  hashing 
function  from  the  key.  An  hsearch  hash  table  entry  consists  of  two  pointers:  (1)  a 
key  pointer  and  (2)  a  supplementary  data  pointer.  The  key  pointer  simply  gives 
the  location  within  the  application  program  (here  the  SDML  parser)  where  the  key 
resides  for  that  entry  and  the  supplementary  data  pointer  gives  the  location  within 
the  application  program  where  any  additional  data  is  stored.  The  size  of  the  hash 
table  is  determined  at  the  time  that  the  first  entry  must  be  made.  If  the  user  did 
not  change  the  minimum  size  of  the  hash  table  (using  the  "%h"  control),  a  default 
minimum  size  is  used. 

The  key  and  the  additional  data  for  a  symbol  table  entry  are  allocated  within  the 
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SDML  parser.  The  key  for  the  symbol  table  entry  is  named  st_key  and  the 
additional  data  structure  for  the  symbol  table  entry  is  named  st_data.  The 
additional  data  for  the  symbol  table  entry  contain  the  following  data: 

name      :     pointer  to  name  of  symbol  within  the  key 

type      :      type  of  symbol  (part  of  key) 

sup_data  :  supplementary  key  data  (part  of  key) 

usage     :      symbol  usage  count 

table_p    :    pointer  to  table  where  symbol  specific  data  is  stored.   This  can  be 
either  a  class  structure  or  an  attribute  structure. 

The  size  of  the  symbol  table  is  defined  the  same  as  the  size  of  the  hash  table. 
Attribute  structure  location  is  exactly  the  same  as  class  structure  location.  The 
only  difference  is  the  template  used  for  the  memory  pointed  to  by  the  table_p 
pointer. 

Additional  synonymous  names  for  classes  and  attributes  are  also  entered  into  the 
symbol  table  but  have  a  table_p  which  points  to  the  primary  class  or  attribute 
structure.  Thus,  any  references  to  synonymous  names  for  classes  or  attributes  will 
ultimately  result  in  the  same  class  or  attribute  structure  being  referenced. 

6.3.2  Class  and  Attribute  Structures  The  class  and  attribute  structures  contain  all 
information  pertinent  to  the  class  and  attribute  definitions.  These  structures 
contain  the  data  which  defines  how  the  class  or  attribute  was  defined  by  the  user 
in  the  SDM  schema.  The  class  structure  contains  the  following  information: 


103- 


•  index  of  symbol  table  entry  identifying  class 

•  base  vs.  nonbase  indication 

•  parent  class  symbol  table  index 

•  underlying  base  class  symbol  table  index 

•  description  text  (if  any) 

•  if  base  class,  whether  duplicates  are  allowed  or  not 

•  number  of  member  attributes  denned  in  class 

•  index  of  first  member  attribute  defined  in  class 

•  number  of  class  attributes  denned  in  class 

•  index  of  first  class  attribute  defined  in  class 

•  if  base  class,  identifiers  which  uniquely  identify  a  member  of  this  class 

•  if  nonbase  class,  interdass  connection  defining  how  this  class  is  formed  from 
its  parent  class 

•  if  name  nonbase  class,  the  class  symbol  table  index  of  class  which  has  a  value 
class  determined  by  this  class 

•  if  name  nonbase  class,  the  number  of  constant  members  which  are  denned 
within  this  class 

•  if  name  nonbase  class,  the  first  constant  member  symbol  table  index 

The  number  of  classes  and  attributes  which  can  be  defined  is  a  user-controllable 
value  which  can  be  changed  with  the  "95c"  and  "%a"  control  respectively.  The 
attribute  structure  contains  the  following  data: 

•  index  of  symbol  table  entry  for  class  defining  this  attribute 

•  index  of  next  attribute  in  list  (or  nil) 

•  member  vs.  class  attribute 

•  description  text  (if  any) 

•  index  of  symbol  table  entry  for  value  class 

•  Index  of  symbol  table  entry  for  inverse  attribute 
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•  indication  of  match  relationship.    If  match  exists  then  contains:  (1)  derived 
attribute  index,  (2)  matching  class  index,  and  (3)  condition  attribute  index. 

•  Indication  of  derivation  and  actual  derivation 

•  single  valued  vs.  multivalued 

•  if  multivalued,  then  size  range 

•  may  not  be  null 

•  not  changeable 

•  exhausts  value  class 

•  no  overlap  in  values 

•  attribute  assertion  (if  any) 

Based  on  the  contents  of  the  class  and  attribute  structures  given  above,  member 
and  class  attributes  are  lined  using  a  single  link-list  from  the  defining  class  with 
the  attribute  link  of  the  last  class  definition  being  nil.  Each  attribute  has  a  index 
pointer  back  to  the  defining  class. 

6.3.3  Semantic  Checks  The  SDML  grammar  specification  supplied  to  Yacc  will 
contain  all  necessary  semantic  checks  identified  in  Chapter  4  as  actions  for  the 
appropriate  grammar  rule.  All  semantic  checks  will  be  performed  in  pass  2  of  the 
SDML  parser  after  all  symbol  table  entries  are  built.  Any  semantic  errors  detected 
will  not  halt  pass  2  of  the  compile  but  will  simply  issue  warning  messages  with  a 
line  number.  This  will  allow  all  semantic  verifications  to  be  made  at  once;  thus 
allowing  the  user  to  correct  semantic  errors  at  one  time. 

6.3.4  SDML  Parser  Output  The  output  of  the  SDML  parser  will  be  the  structures 
which  are  built  during  passes  1  and  2  of  the  compiler.  These  structures  will 
represent  the  class  and  attribute  definitions  which  were  specified  in  the  SDML 
specification  supplied  by  the  user.  The  hash  table,  however,  will  not  be  generated 
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as  output  since  it's  purpose  was  realized  during  pass  2  of  the  parser  for  symbol 
lookup.  For  this  reason,  all  references  to  classes  or  attributes  are  via  a  direct  index 
into  the  symbol  table.  The  structure  dump  is  requested  by  specifying  -d  on  the 
command  line  (indicating  that  data  dictionary  generation  is  to  be  performed). 

The  generated  SDM  schema  can  be  directed  to  an  output  file  by  specifying  the  -o 
option  on  the  command  line.  An  output  of  the  symbol  table  can  be  requested  by 
using  the  -s  option  on  the  command  line  Finally,  a  verbose  statistics  report  can  be 
requested  by  requesting  the  -v  option  on  the  command  line. 

The  manual  page  associated  with  the  SDML  parser  is  shown  in  Appendix  6. 
6.4  Summary 

This  chapter  has  discussed  the  design  of  the  SDML  parser  for  the  grammar 
designed  in  Chapter  4.  The  design  of  the  SDML  parser  is  primarily  that  of 
specifying  a  suitable  grammar  to  the  Yacc  process  and  supplying  actions  to  be 
performed  when  certain  reductions  are  performed.  The  SDML  grammar  was 
designed  to  be  easily  expandable  and  maintainable.  This  ease  of  expansion  and 
maintainability  is  a  benefit  which  Is  inherent  In  the  use  of  Yacc. 
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Chapter  6:  Conclusion 

This  paper  has  developed  a  grammar  defining  a  Semantic  Database  Model  (SDM) 
language  and  discussed  the  design  of  a  parser  to  parse  the  language.  The  Semantic 
Database  Model  Language  (SDML)  is  used  as  an  intermediate  in  the  generation  of  a 
static  data  dictionary. 

Some  extensions  to  the  SDM  model  which  would  both  enhance  capabilities 
provided  by  the  SDM  model  and  enhance  the  semantic  integrity  provided  by  the 
SDML  specification  over  the  SDM  model  which  were  introduced  follows: 

•  assertions,  which  allow  the  database  designer  to  include  statements  of  fact 
within  the  SDML  specification,  thus  greatly  improving  the  semantic  integrity 
of  the  SDML  specification  over  the  SDM  model, 

•  grouping  name  classes,  which  allow  the  value  of  one  attribute  to  determine 
the  value  class  of  another  attribute, 

•  constant  name  class  members,  which  allow  the  use  of  a  constant  member  of  a 
name  class  within  expressions  in  the  SDML  specification,  and 

•  sizeof  class  and  attribute  operator,  which  allows  the  reference  to  the  number 
of  members  in  a  class  or  multivalued  attribute. 

An  SDML  grammar  which  includes  the  extensions  was  created.  Along  with  the 
presentation  of  the  production  rules  for  the  grammar,  the  semantic  checks  which 
should  be  made  are  listed  for  each  production.  These  semantic  checks  will  provide 
a  mechanism  for  reporting  misuse  of  SDM  features.   The  semantic  checks  ensure 
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that  the  value  class  of  a  member  attribute  Is  consistent  with  the  derivation  for 
that  attribute  and  that  the  interclass  connection  for  a  nonbase  class  is  consistent 
with  the  underlying  base  class  and  all  classes  referenced  in  the  connection.  The 
semantic  checks  also  verify  that  the  member  derivation  rules  which  protect  against 
inconsistent  attribute  derivations  are  enforced. 

The  design  of  the  SDML  parser  for  the  grammar  was  developed.  The  Yacc  program 
was  used  to  automatically  generate  a  shift-reduce  parser  for  the  SDML  grammar. 
Symbol  table  administration  and  semantic  check  routines  were  added  as  actions  to 
SDML  grammar  rules  to  complete  the  SDML  parser  design. 

7.1   Future  Research  Areas 

Chapter  3  introduced  the  concept  of  assertions  into  the  SDML  specification.  The 
assertions  provided  are  conceived  as  a  minimal  set  of  assertions.  Therefore,  any 
additional  assertions  which  could  be  identified  would  add  even  more  to  the 
semantic  integrity  of  the  SDML  specification. 

Part  of  the  failure  action  for  an  assertion  and  the  violation  action  for  format 
directives  is  the  ability  for  the  database  designer  to  specify  user-defined  procedures 
within  the  SDML  specification  to  generalize  the  failure  action.  The  SDML 
specification  could  be  expanded  to  allow  definition  of  these  procedures  (procedure 
specifications)  within  the  SDML  specification. 

Chapter  3  also  talked  about  the  possibility  of  specifying  an  additional  failure 
action  which  would  indicate  the  manner  in  which  the  database  should  be  corrected 
in  order  to  return  to  a  valid  database  state.  This  idea  is  implicit  in  the  SDML 
specification  presented  here  in  that  database  repair  is  considered  a  function  of  a 
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user-defined  procedure.  This  concept,  however,  could  be  explicitly  specified  In  the 
SDML  specification,  thus  providing  more  semantic  information  within  the  model. 

Some  of  the  constructs  provided  by  the  SDM  model  presented  by  Hammer  and 
McLeod  can  be  difficult  to  understand.  For  this  reason,  the  SDM  model  will 
probably  not  be  realized  as  a  widely  used  database  modeling  mechanism.  Some  of 
the  constructs  provided  In  the  SDM  model  could  be  combined  to  form  a  more 
uniform  set  of  capabilities  instead  of  seamingly  ad-hoc  capabilities.  On  a  larger 
scale,  the  development  of  a  new  SDM  model,  based  on  concepts  from  the  old  SDM, 
may  be  desirable.  The  new  SDM  model  should  provide  a  cohesive  set  of 
capabilities  (probably  not  unlike  the  old  SDM)  which  are  easy  to  understand  and 
use. 


109- 


References 

1.  Hammer,  M.  and  McLeod,  D„  "Database  Description  with  SDM:  A  Semantic 
Database  Model,"  ACM  T-DS,  Vol.  6,  No.  3,  Sept.  1981,  pp.  351-386. 

2.  Hammer,  M.  and  McLeod,  D.,  "The  Semantic  Data  Model:  A  Modelling 
Mechanism  for  Data  Base  Applications,"  ACP  SIGMOD,  Auston,  Texas  1978 
pp.  26-36. 

3.  Hammer,  M.  and  McLeod,  D.,  "A  Framework  for  Data  Base  Semantic 
Integrity,"  Proc.  2nd  Int.  Conf.  Software  Engineering,  San  Francisco,  Calif. 
Oct.  1976,  pp.  498-504. 

4.  Hammer,  M.  and  McLeod,  D.,  "Semantic  Integrity  In  a  Relational  Data  Base 
System,  Proc.  Int.  Conf.  Very  Urge  Databases,  Framingham,  Mass.,  Sept. 
1975,  pp.  25-47. 

5.  McLeod,  D.  and  King,  R„  "Applying  a  Semantic  Database  Model,"  in  Entity- 
Relationship  Approach  to  Systems  Analysis  and  Design,  P.  P.  Chen  [Ed.] 
North-Holland,  1980,  pp.  193-210. 

6.  Roussopoulos,  N.  and  Mylopoulos,  J.,  "Using  Semantic  Networks  for  Data 
Base  Management,"  Proc.  Int  Conf.  Very  Large  Databases,  Framingham, 
Mass.,  Sept.  1975,  pp.  144-172. 

7.  Su,  S.  Y.  W.  and  Lo,  D.  H,  "A  Semantic  Association  Model  for  Conceptual 
Database  Design,"  in  Entity-Relationship  Approach  to  System  Analysis  and 
Design,  P.  P.  Chen  [Ed.],  North-Holland,  1980,  pp.  169-192. 

8.  Roussopoulos,  N.,  "ADD:  Algebraic  Data  Definition,"  Proc,  6th  Texas  Conf 
Computing  Systems,  Auston,  Texas,  Nov.  1977,  pp.  1C-16  to  1C-25. 

9.  Lee,  R.  M.  and  Gerritsen,  R.,  "Extended  Semantics  for  Generalization 
Hierarchies,"  ACM  SIGMOD,  Auston,  Texas,  1978,  pp.  18-25. 

10.  Barrett,  W.  A.  and  Couch,  J.  D.  [1979],  Compiler  Construction:  Theory  and 
Practice,  Science  Research  Associates. 

11.  Gries,  D.  [1971],  Compiler  Construction  for  Digital  Computers,  Wiley,  New 

12'    £?5".  A\Y/  ,and„uilman.  J-   D.   [1979],   Principles  of  Compiler  Design, 
Addison-Wesley,  Reading,  Massachusetts. 

13.  McLeod,  D.  J.,  "High  Level  Definition  of  Abstract  Domains  in  a  Relational 
Data  Base  System,"  Computer  Languages,  Vol.  2,  No.  3,  1977,  pp.  61-73. 

14.  Lesk,  M.  E.  and  Schmidt,  E.,  "Lex  -  A  Lexical  Analyzer  Generator,"  Bell 
Laboratories,  Murray  Hill,  New  Jersey. 


110- 


15.    Johnson,  S.  C,  "Yacc  Yet  Another  Compiler-Compiler,"  Bell  Laboratories 
Murray  Hill,  New  Jersey. 


■Ill 


Appendix  1:  Example  SDM  Schema 


This  Appendix  contains  an  example  of  an  SDM  schema  to  aid  in  the  understanding 
of  the  concepts  presented  in  Chapter  2  of  this  paper.  This  example  represents  the 
SDM  schema,  as  it  was  presented  by  Hammer  and  McLeod  in  reference  [1]. 

CARS  and  AUTOMOBILES 

description:  All  cars  produced  by  a  plant. 
This  is  a  base  class  definition, 
duplicates  not  allowed 
member  attributes: 

Make 

value  class:  CAR_TYPES 
may  not  be  null 
not  changeable 

Model 

value  class:  CAR_MODELS 
may  not  be  null 
not  changeable 

Year 

value  class:  YEARS 
may  not  be  null 
not  changeable 

Exterior_color 

value  class:  COLORS 

Interior_color 

value  class:  COLORS 

Base_price 

value  class:  PRICES 

Sticker_price 

value  class:  PRICES 

derivation:  -  Base_price  +  sumC  Options.Price  ) 

Options 

description:  Options  on  car 
value  class:  OPTIONS 
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Appendix  1  -  Example  SDM  Schema 


Dealership 

description:  Dealership  stocking  this  car. 

This  attribute  shows  the  inverse 
relationship.  Here,  Dealership  is 
the  DEALER  with  this  car  in  stock. 

value  class:  DEALERS 

inverse:  Cars_in_stock 

Vin 

description:  Vehicle  Identification  Number 
value  class:  VIN_CODES 
may  not  be  null 
not  changeable 

Owner 

description:  Ultimate  owner  of  vehicle  until 

purchased  by  a  consumer.  This  attribute 
shows  the  matching  relationship.  Here, 
Owner  Is  the  owner  of  the  Dealership 
which  has  this  car  in  stock. 

value  class:  OWNERS 

match:  Owned_by  of  DEALERS  on  Cars_in_stock 

identifiers: 
Vin 

DEALERS,  DEALERSHIPS 

description:  Car  dealerships  which  stock  the  cars  built 
by  a  plant.  This  is  a  base  class  definition, 
member  attributes: 

Name 

description:  Dealership  name 
value  class:  DEALER_NAMES 

Address 

value  class:  ADDRESS 

Dealer_code 

description:  Code  uniquely  identifying  a  dealership 
value  class:  DEALER_CODES 
may  not  be  null 

Makes 

description:  Makes  of  cars  which  this  dealer  carries 

value  class:  CAR_TYPES 

multivalued 
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Cars_in_stock 

description:  Cars  which  this  dealership  has  in  stock. 
This  attribute  closes  the  symmetrical 
inverse  relationship  with  the  Dealership 
attribute  of  class  CARS. 

value  class:  CARS 

inverse:  Dealership 

multivalued 

Owned_by 

description:  Owners  of  this  dealership 
value  class:  OWNERS 
inverse:  Dealers_owned 

Employees 

description:  Employees  working  as  sales  persons  for 

this  dealership. 
value  class:  PERSON_NAMES 
multivalued  with  size  between  1  and  20 

class  attributes: 

Number_dealer_cars 

description:  Number  of  cars  in  dealership. 

value  class:  INTEGERS 

derivation:  number  of  members  in  Cars_in_stock 

identifiers: 

Dealer_code 

OWNERS 

description:  This  class  contains  all  owners  of  car 

dealerships.  This  is  a  base  class  definition, 
member  attributes: 

Name 

value  class:  PERSON_NAMES 

Address 

value  class:  ADDRESS 

Dealers_owned 

description:  This  attribute  is  the  dealerships 

which  this  person  or  persons  own. 
value  class:  DEALERS 
inverse:  Owned_by 
multivalued 

identifiers: 
Name 
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OPTIONS 

description:  This  base  class  contains  all  available 

car  options, 
member  attributes: 

Type 

description:  Type  of  option 
value  class:  OPTION_TYPES 

Price 

description:  Price  of  options 
value  class:  PRICES 

identifiers: 
Type 

CARS_SOLD 

description:  This  class  contains  all  cars  sold  to  a 

customer, 
interclass  connection:  subclass  of  CARS  where  specified 
member  attributes: 

Sold_to 

description:  Customer  buying  the  car. 
value  class:  PERSON_NAMES 
may  not  be  null 

Sold_by 

description:  Salesman  selling  car  to  customer, 
value  class:  PERSON_NAMES 
may  not  be  null 

Customer_address 

value  class:  ADDRESS 

Date_sold 

value  class:  DATES 

Selling_price 

description:  Final  selling  price  of  car. 
value  class:  PRICES 

class  attributes: 

Number_of_cars_sold 
value  class:  INTEGERS 
derivation:  number  of  unique  members  in  this  class 
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SCHEDULED_PREPS 

description:  This  class  contains  all  scheduled  car 

preparations.  This  base  class  definition 
is  an  example  of  an  event  class  definition. 

interclass  connection:  subclass  of  CARS  where  specified 

member  attributes: 

Date_of_preparation 
value  class:  DATES 

class  attributes: 

Number_of_sched_preps 

description:  number  of  cars  to  be  prepared 

value  class:  INTEGERS 

derivation:  number  of  unique  members  in  this  class 

BUICKS 

description:  This  class  contains  all  Buick  cars.  This 
nonbase  class  shows  the  use  of  the 
attribute-defined  subclass  connection  utilizing 
the  simple  attribute  predicate. 

interclass  connection:  subclass  of  CARS  where  Make  -  'Buick' 

member  attributes: 

Model 

description:  this  shows  the  concept  of  restricting 

the  value  class  of  an  inherited  member 

attribute. 
value  class:  BUICK_MODELS 

SOMERSETS 

description:  This  class  contains  all  Buick  Somerset  model 
cars.  This  nonbase  class  definition  shows 
the  use  of  the  attribute-defined  subclass 
connection  utilizing  the  compound  attribute 
predicate.  Note  that  the  interclass  connection 
for  this  class  could  also  have  been  "subclass 
of  BUICKS  where  Model  -  'Somerset'", 
interclass  connection:  subclass  of  CARS  where 

Make  -  'Buick'  and 
Model  -  'Somerset' 

PREPARED_CARS 

description:  This  class  contains  all  prepared  cars  for 

any  dealership.  This  nonbase  class  definition 
shows  the  use  of  the  user-controllable 
subclass  connection. 

interclass  connection:  subclass  of  CARS  where  specified 
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PREPARED_BUICKS 

description:  This  class  contains  all  prepared  Buick's  for 
any  dealership.  This  nonbase  class  definition 
shows  the  use  of  the  intersection  set-operator-defined 
subclass  connection.  Note  that  the  interclass 
connection  for  this  class  could  also  have  been 
"subclass  of  PREPARED_CARS  where  Make  -  'Buick"'. 
interclass  connection:  subclass  of  CARS  where  is  in  BUICKS  and 

is  in  PREPARED_CARS 

BUICK_DEALERS 

description:  This  class  contains  all  of  the  dealers  which 

sell  Buick's.  This  nonbase  class  definition  shows 
the  use  of  the  existence  subclass  connection. 
Note  that  the  interclass  connection  for  this 
class  could  also  have  been  "subclass  of  DEALERS 
where  Makes  contains  'Buick'"  (which  is  an 
attribute-defined  subclass  connection). 

Interclass  connection:  subclass  of  DEALERS  where  is  a  value  of 
Dealership  of  BUICKS 

CAR_MODEL_GROUPS 

description:  This  class  groups  cars  into  models.  This 

nonbase  class  definition  shows  the  use  of  the 
expression-defined  grouping  class.  Each  member 
of  this  nonbase  class  is  a  class  containing  all 
models  for  cars.  Note  that  the  class  definition 
also  indicates  that  a  SDM  class  was  explicitly 
defined  for  the  Buick  Somerset  make  and  model. 

interclass  connection:  grouping  of  BUICKS  on  common  value  of 

Make  and  Model 

groups  defined  as  classes  are  SOMERSETS 

DEALER_PREP_CARS 

description:  This  class  groups  prepared  cars  for  specific 
dealerships.  This  nonbase  class  definition 
also  shows  the  use  of  the  expression-defined 
grouping  class, 
interclass  connection:  grouping  of  PREPARED_CARS  on  common  value 
of  Dealership 

CAR_TYPES 

description:  This  is  the  list  of  all  available  car  types, 
interclass  connection:  subclass  of  STRINGS  where  specified 

CAR_MODELS 

description:  This  is  the  list  of  all  available  car  models, 
interclass  connection:  subclass  of  STRINGS  where  specified 
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BUICK_MODELS 

description:  This  is  the  list  of  all  possible  buick  car  models, 
interclass  connection:  subclass  of  STRINGS  where  specified 

YEARS 

description:  This  is  the  format  of  a  year. 

interclass  connection:  subclass  of  STRINGS  where  format  is 

number  where  integer  and  >  -  70  and  <=  99 

DATES 

description:  Calendar  dates  in  the  range  "1/1/70"  to  "12/31/99". 
interclass  connection:  subclass  of  STRINGS  where  format  is 
month:  number  where  integer  and 

>-l  and  <-12 
'/' 
day:  number  where  integer  and 

>-l  and  <-31 
'/• 
year:  number  where  integer  and 

>-70  and  <-99 
where  (if  (month-4  or  month-5  or 

month-9  or  month=l  1)  then 
day  <-30)  and 
(if  month-2  then  day  <-29) 
ordering:  year,  month,  day 

COLORS 

description:  This  is  the  available  interior  and  exterior 

car  colors, 
interclass  connection:  subclass  of  STRINGS  where  specified 

PRICES 

description:  This  is  the  possible  car  prices, 
interclass  connection:  subclass  of  STRINGS  where  format  is 
number  where  >  -  0 
where  lengthC  right(*,  '.'+1)  )  -  2 

or  not  present(  *,  '.'  ) 
ordering:  value 
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VIN_CODES 

description:  This  is  the  format  of  the  Vehicle  Identification 

Number  Codes.  For  example:  1G4NK27U1GC612345. 
interclass  connection:  subclass  of  STRINGS  where  format  is 
'1G' 

number  where  integer  and  >=0  and  <-9 
string  where  has  alphabetics  and  size  -  2 
string  where  has  numerics  and  size  -  2 
engine_code:  oneof  'U',  'G' 

number  where  integer  and  >-0  and  <=9 
model_year:  string  where  has  alphabetics  and  size  =  1 
assy_plant:  string  where  has  alphabetics  and  size  =  1 

string  where  has  numerics  and  size  -  6 
ordering:  call  _vin_ordering 

DEALER_NAMES 

description:  Dealership  names 

interclass  connection:  subclass  of  STRINGS 

ADDRESS 

description:  Street  Address 

interclass  connection:  subclass  of  STRINGS 

DEALER_CODES 

description:  Dealership  identifier  codes 
interclass  connection:  subclass  of  STRINGS  where  format  is 
number  where  integer 

PERSON_NAMES 

description:  Personal  Names 

interclass  connection:  subclass  of  STRINGS 

OPTION_TYPES 

description:  Option  types 

interclass  connection:  subclass  of  STRINGS  where  specified 
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The  structure  specification  used  here  and  in  Appendix  3  utilize  the  following 
notational  conveniences: 

1.  Productions  are  shown  in  the  form  LHS  -  RHS,  which  is  read:  LHS  "is 
made  up  or  RHS. 

2.  The  RHS  of  each  production  is  indented  once  to  enhance  reading  ability.  All 
further  indentation  is  typically  supplied  (but  not  required)  within  the  SDM 
schema. 

3.  X+  means  one  or  more  occurrences  of  X,  concatenated  together. 

4.  <X>  means  that  one  or  more  occurrences  of  X  with  appropriate  separators 
Ce.g.,  comma's  or  and's)  are  allowed. 

5.  <<*>>  means  that  one  or  more  occurrences  of  X  are  listed  vertically 
with  no  separators. 

6.  {  X  I  Y  }  means  that  exactly  one  ofXorr  can  be  used. 

7.  [X]  means  that  X  is  optional. 

8.  A  meta-description  will  be  enclosed  in  stars  Ce.g.,  *  this  is  a  meta-description 

9.  Reducible  constructs  are  shown  in  upper-case,  whereas  all  non-reducible 
constructs  are  shown  in  lower-case. 

Those  productions  or  lines  marked  with  an  asterik  (*)  are  extensions  to  the  SDM 
schema  presented  in  Chapter2. 
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SCHEMA   <- 

<  <CLASS>  > 

CLASS   - 

{  BASE_CLASS  I  NONBASE_CLASS  I  NAME_CLASS  } 

BASE_CLASS  - 

<CLASS_NAME> 

[description:  DESCRIPTION_TEXT] 
[BASE_CLASS_FEATURES] 
member  attributes: 

<  <MEMBER_ATTRIBUTE>  > 
[class  attributes: 

<  <CLASS_ATTRIBUTE>  >  ] 
identifiers: 

{  <IDENTIFIER>  I  none  } 

NONBASE_CLASS   - 

<CLASS_NAME> 

[description:  DESCRIPTION_TEXT] 

interclass  connection:  INTERCLASS_CONNECTION 

[member  attributes: 

<  <  MEMBER_ATTRIBUTE>  >  ] 
[class  attributes: 

<  <CLASS_ATTRIBUTE>  >  ] 

NAME_CLASS   - 

<CLASS_NAME> 

[description:  DESCRIPTION_TEXT] 

Interclass_connection:  NAME_CLASS_IC 
*  [determines:  CLASS_NAME] 

[constant  members:  CONSTANT_MEMBER_NAME] 

BASE_CLASS_FEATURES  - 

{  duplicates  allowed  I  duplicates  not  allowed  } 

MEMBER_ATTRIBUTE  - 

<  ATTRIBUTE_NAME> 

[description:  DESCRIPTION_TEXT] 

value  class:  CLASS_NAME 

[inverse:  ATTRIBUTE_NAME] 

[{  match:  ATTRIBUTE_NAME  of  CLASS_NAME  on  ATTRIBUTE   NAME  I 

derivation:  MEMBER_ATTRIBUTE_DERIVATION  }]  - 

[{  single  valued  I 

multivalued  [with  size  between  INTEGER  and  INTEGER]  1] 
[may  not  be  null] 
[not  changeable] 
[exhausts  value  class] 
[no  overlap  in  values] 
*  [<ATTRIBUTE_ASSERTION>] 
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CLASS_ATTRIBUTE  - 

<  ATTRIBUTE_NAME> 

[description:  DESCRIPTION_TEXT] 

value  class:  CLASS_NAME 

[derivation:  CLASS_ATTRIBUTE_DERIVATION] 

[(  single  valued  I 

multivalued  [with  size  between  INTEGER  and  INTEGER]  }] 
[may  not  be  null] 
[not  changeable] 

*  [  <  ATTRIBUTE_ASSERTION>  ] 

*  ATTRIBUTE_ASSERTION   - 

assertion:  {  ASSERTION_EXPRESSION  I  call  PROCEDURE   NAME  } 
[failure  action:  FAILURE_ACTION]  - 

»  ASSERTION_EXPRESSION   <- 

MAPPING_EXPRESSION  -  MAPPING_EXPRESSION 

*  FATLURE_ACTION  - 

{  call  PROCEDURE_NAME  I 
error  [STRING]  I 
warning  STRING  } 

IDENTIFIER  <- 

{  ATTRIBUTE_NAME  I 
IDENTIFIER  +  ATTRIBUTE_NAME  } 

MEMBER_ATTRIBUTE_DERIVATION  - 
{  INTERATTRIBUTE_DERIVATION  I 
MEMBER-SPECIFIC_DERIVATION( 

CLASS   ATTRIBUTE_DERIVATION   <- 

riNTERATTRIBUTE_DERIVATION  I 
CLASS-SPECIFIC_DERIVATION} 

INTERATTRIBUTE_DERIVATION  <- 
{  same  as  ATTRIBUTE_NAME  I 
subvalue  of  MAPPING  where  {is  in  CLASS_NAME  I 
ATTRIBUTE_PREDICATE  )  I 
where  {  is  in  MAPPING  and  is  in  MAPPING  I 
Is  in  MAPPING  or  is  in  MAPPING  I 
is  in  MAPPING  and  is  not  in  MAPPING}  I 
-  MAPPING_EXPRESSION  I 
number  of  [unique]  members  in  MAPPING  } 

MEMBER-SPECrFIC_DERIVATION   - 

(  order  by  [{  increasing  I  decreasing  )]  <MAPPING> 
[within  <MAPPING>]I 
if  in  CLASS_NAME  I 
(  up  to  INTEGER  I  all  }  levels  of  values  of 
ATTRIBUTE   NAME} 
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CLASS-SPECIFIC_DERIVATION  - 

{  number  of  [unique]  members  in  this  class  I 
SET_FUNCTION  of  ATTRIBUTE_NAME  over  members  of  this  class  } 

MAPP1NG_EXPRESSI0N   - 
{  MAPPING  I 
(  MAPPING_EXPRESSION  )  I 

MAPPING_EXPRESSION  NUMBER_OPERATOR  MAPPING   EXPRESSION  I 
SET_FUNCTION  (  MAPPING  )  I  ~~ 

*  sizeof  C  MAPPING  )  I 

*  sizeof  (  CLASS_NAME  )  } 

MAPPING   - 

{  ATTRIBUTE_NAME  I 
MAPPING  .  ATTRIBUTE_NAME  } 

NUMBER_OPERATOR   «- 

SET_FUNCTION  - 

{  minimum  I  maximum  I  average  I  sum  } 

INTERCLASS_CONNECTION  - 

{  SUBCLASS_CONNECTION  I 
GROUPING_CONNECTION  } 

*  [  <  DMTERCLASS_ASSERTION>  ] 

*  INTERCLASS_ASSERTION   - 

interclass  assertion:  INTERCLASS   CONNECTION 
[FAILURE_ACTION] 

NAME_CLASS_IC  - 

{  NAME_CLASS_SC  I  NAME_CLASS_GC  ( 

NAME_CLASS_SC  - 

subclass  of  STRINGS  [where  NAME_CLASS_SCPRED] 

NAME  CLASS_SCPRED  - 
(  specified  I 
format  is  FORMAT_DIRECTIVE  /'seeAppendix  3«  /} 

*  NAME_CLASS_GC  - 

grouping  of  STRINGS  where  specified  by  CLASS_NAME 

SUBCLASS_CONNECnON   - 

subclass  of  CLASS_NAME  where  SUBCLASS_PREDICATE 
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GROUPING_CONNECTION   - 

{  grouping  of  CLASS_NAME  on  common  value  of  <  ATTRIBUTE_NAME> 
[groups  denned  as  classes  are  <CLASS_NAME>]  I 
grouping  of  CLASS_NAME  consisting  of  classes  <CLASS_NAME>  I 
grouping  of  CLASS_NAME  as  specified  ( 

SUBCLASS_PREDICATE  - 

I  ATTRIBUTE_PREDICATE  I 
specified  I 

(  is  In  CLASS_NAME  and  is  in  CLASS_NAME  I 
is  not  In  CLASS_NAME  I 
is  in  CLASS_NAME  or  is  in  CLASS_NAME  1 1 
Is  a  value  of  ATTRIBUTE_NAME  of  CLASS_NAME  } 

ATTRIBUTE_PREDICATE  <- 
{  SIMPLE_PREDICATE  I 
(  ATTRIBUTE_PREDICATE  )  I 
not  ATTRIBUTE_PREDICATE  I 

ATTRIBUTE_PREDICATE  and  ATTRIBUTE_PREDICATE  I 
ATTRIBUTE_PREDICATE  or  ATTRIBUTE_PREDICATE  ) 

SIMPLE_PREDICATE  - 

{  MAPPING  RELOP  (  CONSTANT  I  MAPPING  1 1 
MAPPING  SETOP  {  CONSTANT  I  MAPPING  I  CLASS_NAME  }  } 

RELOP  - 

)_|  _KI<_|>  |>_( 

SETOP  - 

{  Is  [properly]  contained  in  I 
[properly]  contains  } 

CLASS_NAME  <- 

UPPER_CASE  NOT_LOWER_CASE+ 

ATTRIBUTE_NAME  - 

UPPER_CASE  NOT_UPPER_CASE+ 

PROCEDURE_NAME  <- 

"_"  NOTJJPPER_CASE  + 

CONSTANT_MEMBER_NAME  - 
"_"  NOT_LOWER_CASE+ 

DESCRIPTION_TEXT  - 

"("  *  any  character  string  except  (  character  *  "}" 

INTEGER  - 
DIGIT* 
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REAL   - 

INTEGER  .  INTEGER 

NUMBER  - 

{ INTEGER  I  REAL  I 

CONSTANT  <- 

{  NUMBER  I  STRING  ( 

UPPER_CASE  *- 

{  A  I  B  I ...  I  Z  } 

LOWER_CASE  <- 
{  a  I  b  I ...  I  z  } 

DIGIT  - 

{  0  I  1  I ...  I  9  } 

NOT_LOWER_CASE  <- 

{  UPPER_CASE  I  _  I  DIGIT  } 

NOT_UPPER_CASE  <- 

{  LOWER_CASE  I  _  I  DIGIT  } 

STRING  - 

"'"  *  any  printable  character  except '  character  *  "'" 
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See  Appendix  2  for  a  description  of  the  notation  used  in  the  following  structure 
specification. 

FORMAT_DrRECTIVE  <- 

DESCRIPTION_CLAUSE 

[ORDERTNG_CLAUSE] 

[VIOLATION_ACTION_CLAUSE] 

DESCRIPTION_CLAUSE  < 

(  DESCRIPTION_SUBCLAUSE  I 
DESCRIPTION_CLAUSE  or  DESCRIPTION_SUBCLAUSE  | 

DESCRIPTION_SUBCLAUSE  - 
DESCRIPTION 
[,  WHERE-RESTRICTION]  . 

DESCRIPTION  «- 

<SUBUNTT> 

SUBUNIT  *- 

[LABEL  :]  SUBUNITJTEM 

SUBUNITJTEM  «- 

{  string  [where  STRING_BOOLEAN]  I 
number  [where  NUMBER_BOOLEAN]  I 
oneof  STRING_LIST  I 
oneof  NUMBER_LIST  I 
STRING} 

STRING_LIST  - 

{  STRTNG_COMPONENT  I 
(  <STRING_COMPONENT>  )  } 

NUMBER_LIST  - 
{NUMBER  I 
(  <NUMBER>  )  } 

STRING_COMPONENT  - 

{  STRING  I  alphabetics  I  numerics  I  specials  } 

STRING_BOOLEAN  - 

{  STRING_PREDICATE  I 
(  STRTNG_BOOLEAN  )  I 
not  STRING_BOOLEAN  I 
STRING_BOOLEAN  and  STRING_BOOLEAN  I 
STRING_BOOLEAN  or  STRING_BOOLEAN  } 
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STRING_PREDICATE  - 

{  if  STRING_CONDITION  then  STRING_PREDICATE  I 
[else  STRING_PREDICATE]  fi  I 
STRTNG_CONDITION  } 

STRING_CONDmON  <- 
{  RELOP  STRING  I 
size  RELOP  INTEGER  I 
has  STRING_LIST  I 
call  PROCEDURE_NAME  } 

NUMBER_BOOLEAN  «- 

(  NUMBER_PREDICATE  I 
(  NUMBER_BOOLEAN  )  I 
not  NUMBER_BOOLEAN  I 

NUMBER_BOOLEAN  and  NUMBER_BOOLEAN  I 
NUMBER_BOOLEAN  or  NUMBER_BOOLEAN  j 

NUMBER_PREDICATE  - 

{  if  NUMBER_CONDITION  then  NUMBER_PREDICATE  i 
[else  NUMBER_PREDICATE]  fi  I 
Integer  I 
real  I 
NUMBER_CONDITION  } 

NUMBER_CONDITION   <- 
!  RELOP  NUMBER  I 
call  PROCEDURE_NAME  } 

WHERE-RESTRICnON   - 
where  BOOLEAN 

BOOLEAN  - 

{  PREDICATE  I 
( BOOLEAN  )  I 
not  BOOLEAN  I 
BOOLEAN  and  BOOLEAN  I 
BOOLEAN  or  BOOLEAN  } 

PREDICATE  - 

{  if  CONDITION  then  PREDICATE  [else  PREDICATE]  fi  I 
CONDITION  } 

CONDITION   - 

{  EXPRESSION  RELOP  EXPRESSION  I 
present  (  EXPRESSION  ,  STRING_LIST  )  I 
call  PROCEDURE   NAME  I 
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EXPRESSION   <- 

(  SUBEXPRESSION  I 
(  EXPRESSION  )  I 
EXPRESSION  RELOP  EXPRESSION  ) 

SUBEXPRESSION  - 

{  ATOMIC_EXPRESSION  I 
SET_FUNCTION  (  <EXPRESSION>  )  I 
append  (  EXPRESSION  ,  EXPRESSION  )  I 
substring  (  EXPRESSION  ,  CHAR_POS  ,  CHAR_POS  )  I 
left  (  EXPRESSION  ,  CHAR_POS  )  I 
right  C  EXPRESSION  ,  CHAR_POS  )  I 
location  (  EXPRESSION  ,  EXPRESSION  )  I 
length  (  EXPRESSION  )  I 
repetitions  LABEL  through  LABEL  } 

ATOMIC_EXPRESSION   - 
(LABEL  I 
STRING  I 

[{  +  I  -  }]  NUMBER  I 
*} 

CHAR_POS  - 

{STRING  I 
STRING  { +  I  -  }  INTEGER  I 
INTEGER} 

ORDERING_CLAUSE  - 

ordering :  ORDERING 

ORDERING   - 

f  <LABEL>  I 
none  I 
atomic  I 
call  PROCEDURE_NAME  } 

VIOLATION  ACTION_CLAUSE  - 
{  errortSTRING]  I 
call  PROCEDURE_NAME  } 
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This  Appendix  contains  the  SDML  grammar  specification  as  given  to  the  Yacc 
program. 

sdm_schema  :  class_definition_list 

class_definition_list  :  class_definition 

I  class_definition_list  class_definition 

class_definition :       base_class_definition 
I  nonbase_class_def 

base_class_definition  :         class_name_list  base_class_body 

class_name_list        :  CLASS_NAME 


I 


class_name_list  comma_and_sep  CLASS_NAME 


comma_and_sep       : 

I  AND 


base_class_body       :  desc_clause  bc_feat_decl 

member_attr_ded  class_attr_ded  ident_decl 

desc_clause    :  /*  empty  */ 

I  DESCRIPTION  ':'  DESCRIPTION_TEXT 

I 

bc_f  eat_decl :  /*  empty  */ 

I  DUPLICATES  ALLOWED 

I  DUPLICATES  NOT  ALLOWED 

f 

member_attr_decl :  MEMBER_ATTRIBUTES  ':'  member_attr_list 

member_attr_list :  member_attribute 

I  member_attr_list  member_attribute 

member_attribute  :  attr_name_list  desc_clause  value_class_decl 
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inverse_decl  match_or_derivation 
member_order  member_attr_opts 
attr_assertion_decl 

attr_name_llst         :  ATTRIBUTE_NAME 

I  attr_name_list  comma_and_sep  ATTRIBUTE_NAME 

value_class_decl :     VALUE_CLASS  ':'  CLASS_NAME 

lnverse_decl  :  /*  empty  V 

I  INVERSE  ':'  ATTRIBUTE_NAME 

match_or_derivation  :         /*  empty  */ 
I  match_decl 

I  derivation_decl 

match_decl    :  MATCH  V  ATTRIBUTE_NAME  OF  CLASS_NAME  ON  ATTRIBUTES 

derivation_decl         :  DERIVATION  ':'  member_attr_deriv 

member_order  :  /*  empty  V 

I  STNGLE_VALUED 

I  MULTIVALUED 

I  MULTIVALUED  WITH_SIZE_BETWEEN  INTEGER_C  AND  INTEGE 

member_attr_opts  :  /*  empty  V 

I  member_options 

member_options       :  member_opt_item 

I  member_options  member_opt_item 

member_opt_item    :  MAY_NOT_BE_NULL 

I  NOT  CHANGEABLE 

I  EXHAUSTS  VALUE_CLASS 

I  NO_OVERLAP_IN_VALUES 

attr_assertion_decl :  /*  empty  V 

I  attr_assertion_list  fail_action_clause 
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attr_assertion_llst  :  attribute_assertion 

attr_assertion_list  attribute_assertion 


I 


attribute_assertlon  :  ASSERTION  ':'  assertion 


assertion 


CALL  PROCEDURE_NAME 
mapping_expression  relop  mapping_expression 
setop_predicate 


fail_action_clause  : 
I 


/*  empty  */ 

FAILURE_ACT10N  ':'  failure  action 


failure_action  :  CALL  PROCEDURE_NAME 

I  ERROR  action_message 

I  WARNING  STRING   C 


class_attr_decl 
I 


:  /*  empty  */ 

CLASS_ATTRIBUTES  ':'  class_attr_llst 


class_attr_llst 
I 


:  class_attribute 

class_attr_list  class_attribute 


class_attrlbute  :  attr_name_list  desc_clause 

value_class_decl  class_deriv_decl 
member_order  class_attr_opts 
attr_assertion   decl 


class_attr_opts 
I 


:  /*  empty  */ 

class_options 


class_options : 

I 


class_opt_item 
class_options  class_opt_item 


class_opt_item 
I 


:  MAY_NOT_BE_NULL 

NOT  CHANGEABLE 


class_deriv_decl : 
I 


/*  empty  */ 

DERIVATION  ':'  class   attr   deriv 
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member_attr_deriv :  interattr_deriv 

I  member_spec_deriv 

member_spec_deriv  :  ordering predicate 

I  existence_predicate 

I  recursive_trace_pred 

ordering_predicate  :  ORDER  BY  direction  mapping_list  within_clause 

direction         :  /*  empty  */ 

I  INCREASING 

I  DECREASING 

within_clause  :  /*  empty  V 

I  WITHIN  mapping_list 

mapping_list :  mapping 

I  mapping_list  comma_and_sep  mapping 

existence_predicate  :IF  IN  CLASS_NAME 

recursive_trace_pred  :         level_clause  LEVELS_OF_VALUES  OF  ATTRIBUTE_NAME 

level_clause   :  UP_TO  INTEGER_C 

I  ALL 

t 

class_attr_deriv :     interattr_deriv 
I  class_spec_deriv 

class_spec_deriv :     class_size_pred 

I  class_member_pred 

class_size_pred         :  NUMBER  OF  uniqueness  MEMBERS  IN  THIS_CLASS 

uniqueness      :  /*  empty  */ 

I  UNIQUE 

class_member_pred  :  set_f unction  OF  ATTRIBUTE_NAME  OVER  MEMBERS  OF  TIE 


132- 


Appendix  4  -  YACC  SDML  Grammar  Specification 


set_functlon  :  MINIMUM 

I  MAXIMUM 

I  AVERAGE 

I  SUM 


lnterattr_deriv  :  derived_predicate 

I  subvalue_predicate 

I  set_derived_pred 

I  equality_predicate 

I  set_order_predicate 


derived_predicate  :   SAME_AS  mapping 


set_derived_pred  :    WHERE  IS  IN  mapping  AND  IS  IN  mapping 
I  WHERE  IS  IN  mapping  OR  IS  IN  mapping 

I  WHERE  IS  IN  mapping  AND  IS  NOT  IN  mapping 


equallty_predicate  :  EQ  mapping_expression 


mapping_expression :  mapping_term 

I  mapping_expression  addition_operator  mapping_term 

mapping_tenn  :  mapping_factor 

I  mapping_term  multiply _operator  mapptng_factor 


mapptng_f  actor        :  mapping_primary 

I  mapping_f  actor  expo nent_opera tor  mapping_primary 


mapping_primary     :  '('  mapping_expression  ')' 

I  set_function  '('  mapping  ')' 

I  mapping 

I  number 

I  CONST_MEMBER_NAME 

I  SIZEOF  '('  mapping  ')' 

I  SIZEOF  '('  CLASS_NAME  ')' 


additlon_operator  :   '+' 

i  -  vj : 
i 
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multiply_operator  :  '*' 

f  -  '«•; } 

i  -  7'; } 


exponent_operator : '!' 


set_order_predicate  :  NUMBER  OF  uniqueness  MEMBERS  IN  mapping 

subvalue_predicate  :  SUB  VALUE  OF  mapping  WHERE  subvalue_selection 

subvalue_selection  :  IS  IN  CLASS_NAME 
I  attribute__predicate 


mapping  :  ATTRIBUTE_NAME 

I  mapping  '.'  ATTRIBUTE_NAME 


ident_ded      :  IDENTIFIERS ':'  ident_list 

I  IDENTIFIERS  ':'  NONE 


ident_Ust       :  identifier 

I  ident_list  ','  identifier 


identifier         :  ATTRIBUTE_NAME 

I  identifier  '+'  ATTRIBUTE_NAME 


nonbase_class_def  :  class_name_list  nonbase_class_body 


nonbase_class_body  :  desc_clause  interclass_connection 

nonbase   class   alts 


nonbase_class_alts  :nonbase_class_feat 
I  name  class   feat 


nonbase_class_feat :  nbc_member_attr_decl  class_attr_decl 
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nbc_member_attr_decl  :     /*  empty  V 
I  member_attr_decl 


name_class_feat  :     determines_clause 

I  const_members_clause 

I  determines_clause  const_members_clause 

determines_clause  :  DETERMINES  ':'  CLASS_NAME 

const_members_clause  :      CONSTANT_MEMBERS  ':'  const_members_list 

const_members_Ust :  CONST_MEMBER_NAME 

I  const_members_list  comma_and_sep  CONST_MEMBER_NAME 

interclass_connectlon  :         INTERCLASS_CONNECTION  ':'  connection 
ic  assertion   decl 


ic_assertion_decl :    /*  empty  V 

I  ic_assertion_list  fail   action  clause 


ic_assertion_list  :     ic_assertion 

I  ic_assertion_list  ic_assertlon 


ic_assertion    :  INTERCLASS_ASSERTION  *:'  connection 


connection      :  subclass_connection 

I  grouping_connection 


subclass_connection  :  SUBCLASS  OF  CLASS_NAME  subclass_predicate 


grouplng_connectlon :  expression_defined_gc 

I  enumerated_gc 

I  user_controllable_gc 

I  name_class_gc 


subclass_predicate  :  WHERE  attribute_predicate 
I  WHERE  SPECIFIED 

I  WHERE  set_oper_defined_sc 

I  WHERE  existence_sc 
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I  name  class  sc 


set_oper_defined_sc  :  IS  IN  CLASS_NAME  AND  IS  IN  CLASS_NAME 

I  IS  IN  CLASS_NAME  OR  IS  IN  CLASS_NAME 

I  IS  NOT  IN  CLASS   NAME 


existence_sc   :  IS  A_VALUE  OF  ATTRIBUTE_NAME  OF  CLASS_NAME 

name_class_sc  :  /*  empty  */ 

I  WHERE  FORMAT  IS  f ormat_directive 

expression_defined_gc  :       GROUPING  OF  CLASS_NAME  ON_COMMON_VALUE  OF 
attr_name_list  explicitly _def_grps 

explicitly _def_grps  :  /*  empty  V 

I  GROUPS_DEFINED_AS_CLASSES_ARE  class_name_list 

enumerated_gc  :  GROUPING  OF  CLASS_NAME  CONSISTING_OF_CLASSES 

class_name_list 

user_controllable_gc  :         GROUPING  OF  CLASS_NAME  AS_SPECIFIED 

name_class_gc  :  GROUPING  OF  CLASS_NAME  AS_SPECIFIED 

BY  CLASS_NAME 

attrlbute_predlcate  :attr_pred_term 

I  attribute_predicate  OR  attr_pred_term 

attr_pred_term         :  attr_pred_factor 

I  attr_pred_term  AND  attr_pred_factor 

attr_pred_factor :    attr_pred_primary 

I  NOT  attr_pred_primary 

attr_pred_prlmary  :  '('  attribute_predicate  ')' 

I  simple_predicate 


simple_predicate :     relop_predicate 
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setop_predicate 


relop_predicate  :       mapping  relop  constant 
I  mapping  relop  mapping 

setop_predicate  :       mapping  setop  constant 
mapping  setop  mapping 
I  mapping  setop  CLASS_NAME 


relop  :  EQ 

I  NE 

i  LT 

I  LE 

I  GT 

I  GE 


setop  :  IS  properly  CONTAINED  IN 

I  properly  CONTAINS 


properly         :  /*  empty  */ 

I  PROPERLY 


format_directive :     description_clause  ordering_clause 
vlolation_actn_clause 


description_clause :  description_subclause 

I  description_clause  OR  description_subclause 

description_subclause :        description  '.' 

I  description  ','  where_restriction  '.' 

description      :  subunit 

I  description  ','  subunit 

» 

subunit  :  subunit_item 

I  LABEL  ':'  subunit_item 


subunlt_item:  STRING  str_where_clause 

I  NUMBER  num_where_clause 

I  ONEOF  string_list 
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I  ONEOF  number_list 

I  STRING   C 


str_where_clause  :   /*  empty  */ 

I  WHERE  string_boolean 


num_where_clause  :  /*  empty  */ 

I  WHERE  number   boolean 


string_llst      :  string_component 

I  '('  string_list  ','  string_component  ')' 


strlng_component  :  STRING_C 

I  ALPHABETICS 

I  NUMERICS 

I  SPECIALS 


numberjist  :  number 

I  '('  number_list  ','  number  ')' 


strtng_boolean  :  string_bool_term 

I  strlng_boolean  OR  string_bool_term 


strlng_boo!_term  :   string_bool_f actor 

I  strlng_bool_term  AND  strlng_bool_f actor 


string_bool_f actor  :string_bool_primary 

I  NOT  strlng_bool_primary 


string_bool_primary  :         '('  string_boolean  ')' 
I  string_predicate 


string_predicate  :      IF  string_condition  THEN  string_predicate  FI 
I  IF  string_condition  THEN  strlng_predlcate 

ELSE  string_predicate  FI 
I  string_condition 


strlng_conditlon  :      relop  STRING_C 

I  SIZE  relop  INTEGER_C 

I  HAS  string_list 
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CALL  PROCEDURE_NAME 


number_boolean       :  number_bool_term 

I  number_boolean  OR  number_bool_term 


number_bool_term :  number_bool_factor 

I  number_bool_term  AND  number_bool_factor 


number_bool_factor :  number_bool_primary 

I  NOT  number_bool_primary 


number_bool_primary  :      '('  number_boolean  ')' 
I  mimber_predicate 


number_predicate  :  IF  number_condition  THEN  number_predicate  FI 
I  IF  number_condition  THEN  number_predicate 

ELSE  number_predicate  FI 
I  INTEGER 

I  REAL 

I  number  condition 


number_condition  :  relop  number 

I  CALL  PROCEDURE_NAME 


where_restrlction :    WHERE  boolean 


boolean  :  boolean_term 

I  boolean  OR  boolean  term 


boolean_term  :  boolean_factor 

I  boolean_term  AND  boolean_factor 

boolean_factor  :  boolean_primary 

I  NOT  boolean_primary 


boolean_primary      :  '('  boolean ')' 

I  predicate 


predicate         :  IF  condition_expr  THEN  predicate  FI 
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IF  condition_expr  THEN  predicate  ELSE  predicate  FI 
condition 


condition        :  expression  relop  expression 

I  PRESENT  '('  expression  ','  expression  ')' 

I  CALL  PROCEDURE_NAME 


condition_expr  :  condition_term 

I  condition_expr  AND  condition_term 

condition_term  :  condition_factor 

I  condition_term  OR  condition_f actor 

condition_factor  :  '('  condition_expr  ')' 

I  condition 


expression 


:  arithmetic_term 

I  expression  addition_operator  arithmetic_term 


arithmetic_tenn        :  arithmetic_factor 

I  arithmetic_term  multiply_operator  arithmetic_factor 


arithmetic_factor  :    arithmetic_primary 

I  arithmetic_f  actor  exponent_operator  arithmetic_primary 


arithmetic_primary  :  '('  expression  ')' 

I  subexpression 


subexpression:  atomic_expression 

I  set_function  '('  expression_list ')' 

I  APPEND  '('  expression  ','  expression  ')' 

I  SUBSTRING  '('  expression  ','  char_pos  ',' 

char_pos  ')' 

I  LEFT  '('  expression  ','  char_pos  ')' 

I  RIGHT  '('  expression  ','  char_pos  ')' 

I  LOCATION  '('  expression  ','  expression  ')' 

I  LENGTH  '('  expression  ')' 

I  REPETITIONS  LABEL  THROUGH  LABEL 


atomic_expression  :  LABEL 

I  STRING   C 
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number 
addition_operator  number 


expression_list 
I 


:  expression 

expression_list  ','  expression 


char_pos         : 
1 

1 

STRING   C 

STRING   C  addition   operator  INTEGER  C 

INTEGER_C 

ordertng_clause 
1 

:           /*  empty  V 
ORDERING  ':'  ordering 

ordering          : 
1 

1 
1 

ordering_list 

NONE 

ATOMIC 

CALL  PROCEDURE_NAME 

ordering_list  : 
1 

LABEL 

ordering_list ','  LABEL 

violatlon_actn_clause  :        /*  empty  */ 

I  VIOLATION_ACTION  ':'  violation_action 


violatlon_actlon :      ERROR  action_message 

I  CALL  PROCEDURE  NAME 


action_message 

I 


:  /*  empty  */ 

STRING   C 


number 


:  INTEGER_C 

REAL  C 


constant 


STRING_C 

number 

CONST   MEMBER  NAME 


141 


Appendix  5:  Example  SDML  Specification 


This  Appendix  contains  the  SDML  specification  for  the  SDM  schema  example  in 
Appendix  1.  The  SDM  schema  in  Appendix  1  was  changed  to  adhere  to  the  syntax 
of  the  SDML  specification  and  was  enhanced  using  some  of  the  extensions  provided 
in  Chapter  3  of  this  paper. 

CARS  and  AUTOMOBILES 

description:  (  All  cars  produced  by  a  plant. 

This  is  a  base  class  definition.  ) 
duplicates  not  allowed 
member  attributes: 

Make 

value  class:  CAR_TYPES 
may  not  be  null 
not  changeable 

Model 

value  class:  CAR_MODELS 
may  not  be  null 
not  changeable 

Year 

value  class:  YEARS 
may  not  be  null 
not  changeable 

Exterior_color 

value  class:  COLORS 

Interior_color 

value  class:  COLORS 

assertion:  call  _verify_interior_color 

failure  action:  error 

'invalid  exterior/interior  combination' 

Base_price 

value  class:  PRICES 

Sticker_price 

value  class:  PRICES 

derivation:  -  Base_price  +  sum(  Options.Price  ) 

Options 

description:  {  Options  on  car  } 
value  class:  OPTIONS 
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Dealership 

description:  {  Dealership  stocking  this  car. 

This  attribute  shows  the  inverse 
relationship.  Here,  Dealership  is 
the  DEALER  with  this  car  in  stock.  } 

value  class:  DEALERS 

inverse:  Cars_in_stock 

Vin 

description:  {  Vehicle  Identification  Number  ) 
value  class:  VIN_CODES 
may  not  be  null 
not  changeable 

Owner 

description:  {  Ultimate  owner  of  vehicle  until  purchased 
by  a  consumer.  This  attribute  shows 
the  matching  relationship.  Here, 
Owner  is  the  owner  of  the  Dealership 
which  has  this  car  in  stock.  } 

value  class:  OWNERS 

match:  Owned_by  of  DEALERS  on  Cars_in_stock 

identifiers: 
Vin 

DEALERS,  DEALERSHIPS 

description:  (  Car  dealerships  which  stock  the  cars  built  by 

a  plant.  This  is  a  base  class  definition.  } 
member  attributes: 

Name 

description:  |  Dealership  name  } 
value  class:  DEALER_NAMES 

Address 

value  class:  ADDRESS 

Dealer_code 

description:  (  Code  uniquely  identifying  a  dealership  } 
value  class:  DEALER_CODES 
may  not  be  null 

Makes 

description:  {  Makes  of  cars  this  dealer  carries  } 

value  class:  CAR_TYPES 

multivalued 
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Cars_ln_stock 

description:  {  Cars  which  this  dealership  has  in  stock. 
This  attribute  closes  the  symmetrical 
Inverse  relationship  with  the  Dealership 
attribute  of  class  CARS.  } 

value  class:  CARS 

inverse:  Dealership 

multivalued 

assertion:  Cars_in_stock.Make  is  contained  in  Makes 

Owned_by 

description:  (  Owners  of  this  dealership  } 
value  class:  OWNERS 
inverse:  Dealers_owned 

Employees 

description:  {  Employees  working  as  sales  persons  for 

this  dealership.  } 
value  class:  PERSON_NAMES 
multivalued  with  size  between  1  and  20 

class  attributes: 

Number_dealer_cars 

description:  {  Number  of  cars  in  dealership.  } 

value  class:  INTEGERS 

derivation:  number  of  members  in  Cars_in_stock 

identifiers: 

Dealer_code 

OWNERS 

description:  {  This  class  contains  all  owners  of  car 

dealerships.  This  is  a  base  class  definition.  ) 
member  attributes: 

Name 

value  class:  PERSON_NAMES 

Address 

value  class:  ADDRESS 

Dealers_owned 

description:  {  This  attribute  is  the  dealerships 

which  this  person  or  persons  own.  ( 
value  class:  DEALERS 
Inverse:  Owned_by 
multivalued 

identifiers: 
Name 
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OPTIONS 

description:  {  This  base  class  contains  all  available 

car  options.  } 
member  attributes: 

Type 

description:  {  Type  of  option  } 
value  class:  OPTION_TYPES 

Price 

description:  {  Price  of  options  ) 
value  class:  PRICES 

identifiers: 
Type 

CARS_SOLD 

description:  (  This  class  contains  all  cars  sold  to  a 
customer.  } 

interclass  connection:  subclass  of  CARS  where  specified 

interclass  assertion:  subclass  of  CARS  where 

is  in  PREPARED_CARS  or 
is  in  SCHEDULED_PREPS 

failure  action:  warning  'car  not  scheduled  for  preparation' 

member  attributes: 

Sold_to 

description:  {  Customer  buying  the  car.  ( 
value  class:  PERSON_NAMES 
may  not  be  null 

Sold_by 

description:  {  Salesman  selling  car  to  customer.  } 

value  class:  PERSON_NAMES 

may  not  be  null 

assertion:  Sold_by  is  contained  in  Dealership.Employees 

failure  action: 

error  'Salesman  not  employed  by  Dealership' 

Customer_address 

value  class:  ADDRESS 

Date_sold 

value  class:  DATES 

Selling_price 

description:  {  Final  selling  price  of  car.  ( 
value  class:  PRICES 
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class  attributes: 

Number_of_cars_sold 

value  class:  INTEGERS 

derivation:  number  of  unique  members  in  this  class 

assertion:  Number_of_cars_sold  = 

sizeofC  SCHEDULED_PREPS  )  + 
sizeoft  PREPARED_CARS  ) 

failure  action:  call  _determine_cars_not_scheduled 

SCHEDULED_PREPS 

description:  {  This  class  contains  all  scheduled  car 

preparations.  This  base  class  definition 
is  an  example  of  an  event  class  definition.  } 

interclass  connection:  subclass  of  CARS  where  specified 

member  attributes: 

Date_of_preparation 
value  class:  DATES 

assertion:  Date_of_preparation  <-  _CURRENT_DATE 
failure  action:  call  _notif y_past_due 

class  attributes: 

Number_of_sched_preps 

description:  {  Number  of  cars  to  be  prepared  } 

value  class:  INTEGERS 

derivation:  number  of  unique  members  in  this  class 

BUICKS 

description:  {  This  class  contains  all  Buick  cars.  This 
nonbase  class  shows  the  use  of  the 
attribute-defined  subclass  connection  utilizing 
the  simple  attribute  predicate.  } 

interclass  connection:  subclass  of  CARS  where  Make  -  'Buick' 

member  attributes: 

Model 

description:  {  This  shows  the  concept  of  restricting 
the  value  class  of  an  inherited  member 
attribute.  } 
value  class:  BUICK_MODELS 
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SOMERSETS 

description:  {  This  class  contains  all  Buick  Somerset  model 
cars.  This  nonbase  class  definition  shows 
the  use  of  the  attribute-defined  subclass 
connection  utilizing  the  compound  attribute 
predicate.  ( 
interclass  connection:  subclass  of  CARS  where 

Make  -  'Buick'  and 
Model  -  'Somerset' 
interclass  assertion:  subclass  of  BUICKS  where 

Model  -  'Somerset' 

PREPARED_CARS 

description:  {  This  class  contains  all  prepared  cars  for 

any  dealership.  This  nonbase  class  definition 
shows  the  use  of  the  user-controllable 
subclass  connection.  } 

interclass  connection:  subclass  of  CARS  where  specified 

PREPARED_BUICKS 

description:  {  This  class  contains  all  prepared  Buick's  for 
any  dealership.  This  nonbase  class  definition 
shows  the  use  of  the  intersection 
set-operator-defined  subclass  connection.  ( 
interclass  connection:  subclass  of  CARS  where 

is  in  BUICKS  and 
is  in  PREPARED_CARS 
Interclass  assertion:  subclass  of  PREPARED_CARS  where 
Make  -  'Buick' 

BUICK_DEALERS 

description:  {  This  class  contains  all  dealers  which  sell 

Buick's.  This  nonbase  class  definition  shows 
the  use  of  the  existence  subclass  connection.  } 
interclass  connection:  subclass  of  DEALERS  where  is  a  value  of 

Dealership  of  BUICKS 
interclass  assertion:  subclass  of  DEALERS  where 

Make  contains  'Buick' 

CAR_MODEL_GROUPS 

description:  {  This  class  groups  cars  into  models.  This 

nonbase  class  definition  shows  the  use  of  the 
expression-defined  grouping  class.  Each  member 
of  this  nonbase  class  is  a  class  containing  all 
models  for  cars.  Note  that  the  class  definition 
also  Indicates  that  a  SDM  class  was  explicitly 
defined  for  the  Buick  Somerset  make  and  model.  } 

interclass  connection:  grouping  of  BUICKS  on  common  value  of 

Make  and  Model 

groups  defined  as  classes  are  SOMERSETS 
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DEALER_PREP_CARS 

description:  {  This  class  groups  prepared  cars  for  specific 
dealerships.  This  nonbase  class  definition 
also  shows  the  use  of  the  expression-defined 
grouping  class.  } 
lnterclass  connection:  grouping  of  PREPARED_CARS  on  common  value 
of  Dealership 

CAR_TYPES 

description:  {  This  is  the  list  of  all  available  car  types.  ( 
lnterclass  connection:  subclass  of  STRINGS  where  specified 
determines:  CAR_MODELS 

CAR_MODELS 

description:  (  This  Is  the  list  of  all  available  car  models.  } 
lnterclass  connection:  grouping  of  STRINGS  where  specified 
by  CAR_TYPES 

BUICK_MODELS 

description:  {  This  is  the  list  of  all  possible 

bulck  car  models.  } 
lnterclass  connection:  subclass  of  STRINGS  where  specified 

YEARS 

description:  {  This  is  the  format  of  a  year.  ( 

lnterclass  connection:  subclass  of  STRINGS  where  format  is 

number  where  integer  and  >  -  70  and  <-  99. 
constant  members:  _CURRENT_YEAR 

DATES 

description:  {  Calendar  dates  in  the  range 

"1/1/70"  to  "12/31/99".  } 
lnterclass  connection:  subclass  of  STRINGS  where  format  is 
month:  number  where  integer  and 
>-land<-12, 

day:  number  where  integer  and 
>-l  and  <-31, 

year:  number  where  integer  and 

> -70  and  <=99, 
where  if  (month-4  or  month-5  or 

month-9  or  month-11)  then 
day  <-30fiand 
if  month-2  then  day  <-29  fi. 
ordering:  year,  month,  day 
constant  members:  _CURRENT_DATE 

COLORS 

description:  {  This  is  the  available  interior  and  exterior 
car  colors.  } 
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interclass  connection:  subclass  of  STRINGS  where  specified 

PRICES 

description:  (  This  is  the  possible  car  prices.  } 
interclass  connection:  subclass  of  STRINGS  where  format  is 
number  where  >  -  0, 
where  lengthC  right(*,  '.'+1)  )  -  2 

or  not  present(  *,  '.'  ). 
ordering:  value 

VIN_CODES 

description:  {  This  is  the  format  of  the  Vehicle  Identification 

Number  Codes.  For  example:  1G4NK27U1GC6 12345.  } 
interclass  connection:  subclass  of  STRINGS  where  format  is 
'1G', 

number  where  integer  and  >-0  and  <=9, 
string  where  has  alphabetic  and  size  -  2, 
string  where  has  numerics  and  size  =■  2, 
engine_code:oneofC  'U',  'G'  ), 

number  where  integer  and  >=0  and  <-9, 
model_year:  string  where  has  alphabetics  and  size  -  1 , 
assy_plant:  string  where  has  alphabetics  and  size  -  1, 

string  where  has  numerics  and  size  =  6. 
ordering:  call  _vin_ordering 

DEALER_NAMES 

description:  {  Dealership  names  } 
interclass  connection:  subclass  of  STRINGS 

ADDRESS 

description:  {  Street  Address  } 

interclass  connection:  subclass  of  STRINGS 

DEALER_CODES 

description:  (  Dealership  identifier  codes  } 
Interclass  connection:  subclass  of  STRINGS  where  format  is 
number  where  integer. 

PERSON_NAMES 

description:  {  Personal  Names  } 

interclass  connection:  subclass  of  STRINGS 

OPTION_TYPES 

description:  {  Option  types  ) 

interclass  connection:  subclass  of  STRINGS  where  specified 
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NAME 

sdml  -  Semantic  Database  Model  (SDM)  language  compiler 

SYNOPSIS 

sdml  [  -dvsl  ]  [  -o  ofile  ]  [  file  ] 

DESCRIPTION 

Sdml  compiles  the  SDM  specification  from  the  given  file  (standard  input 
default).  The  compilation  involves  two  passes.  Pass  1  will  verify  syntax  of 
the  SDM  specification  and  pass  2  will  verify  semantics  of  the  SDM 
specification.  Types  of  errors  reported  are  class  or  attribute  names  used  but 
not  defined,  multiple  class  or  attribute  name  definitions,  and  inconsistent 
usage  of  various  SDM  capabilities.  An  output  specification  may  be  generated 
from  the  SDML  compiler  by  specifying  the  -o  option  and  a  ofile  to  write  the 
file  to. 

The  available  options  are  as  follows: 

-d  generate  a  file  named  sdm.ddl  which  will  contain  the  structures  built 
during  pass  2  of  the  sdml  compiler.  This  file  is  used  by  the  data 
dictionary  generation  program  to  build  a  static  data  dictionary  from 
the  SDM  specification  given.  Note  that  this  option  does  not  make 
sense  with  the  -1  option. 

-v  verbose  mode.  This  option  will  result  in  a  summary  being  directed  to 
standard  output  with  statistics  on  various  label  definitions  and  usage. 

-s  dumps  the  symbol  table  generated  by  pass  1  (and  2)  of  the  sdml 

compiler  to  standard  output.  The  symbol  table  will  contain 
information  about  symbol  definition  and  usage  on  a  per  symbol  basis. 

-o  generates  the  compiled  SDM  specification  and  puts  it  into  the  file 
named  ofile. 

-1  run  pass   1   only.    This  option  may  be  useful  when  attempting  to 

resolve  syntax  errors  in  a  SDM  specification  without  going  through 
pass  2  (verifying  semantics)  if  error  recovery  is  attempted  by  the 
SDML  compiler. 

The  SDML  compiler  pre-defines  the  maximum  number  of  unique  symbols, 
maximum  number  of  class  definitions,  and  maximum  number  of  attribute 
definitions.  The  maximum  number  of  unique  symbol  definitions  (including 
constant  symbols)  can  be  increased  from  the  default  of  254  symbols  (2s- 1) 
by  using  tie 
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%h  hval 

control  statement  at  the  beginning  of  the  SDM  specification.  This  statement 
will  increase  the  number  of  hash  table  entries  possible  from  the  default  limit 
to  the  next  highest  power  of  2  from  hval .  That  is,  the  new  limit  L  will  be 
selected  such  that  2" "'-1   <   hval    <   2"-l=£. 

The  maximum  number  of  class  definitions  can  be  increased  from  the  default 
of  50  by  using  the 

%c  cval 

control  statement,  where  cval  is  the  new  maximum  number  of  class 
definitions.  The  maximum  number  of  attribute  definitions  can  be  increased 
from  the  default  of  100  by  using  the 

%a  aval 

control  statement,  where  aval  is  the  new  maximum  number  of  attribute 
definitions. 

SEE  ALSO 

R.  V.  Lane,  Semantic  Database  Model  Language  (SDML):  Grammar 
Specification  and  Parser 
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ABSTRACT 

This  paper  describes  the  Semantic  Database  Model  Language  CSDML).  SDML  is  a 
high-level  language  based  on  the  Semantic  Database  Model  (SDM).  SDM  will 
allow  a  database  designer  to  model  a  database  application  while  retaining 
application  data  meaning.  Some  extensions  to  the  SDM  are  introduced  and  are 
incorporated  into  the  SDML  grammar.  SDML  is  used  as  an  intermediate  in  the 
automatic  generation  of  a  static  data  dictionary  for  the  application  environment. 
This  paper  discusses  the  design  of  a  context-free  grammar  for  SDML  and  the  design 
of  an  LRCl)  parser  for  SDML.  The  SDML  parser  will  check  syntactic  and  semantic 
correctness  of  an  SDML  specification. 


